big storage redesign
I began to redesign Storage classes to be clearer. I expose here the
ideas retained. Please comment the api and the algorithms detailed.
I keep the idea of handling Entity objects in a general way, so as we
can imagine to have entities extending or related to external
datasources. Each entity specifies its datasource; a Storage instance is
created foreach datasource.
Relations, inheritance are handled at Storage level. A subclass like
StorageSQL must implement low-level actions as set,get,del and get the
opportunity to handle directly inheritance and relations if they are
able to (for example in sql, Get can be done for all inheritance with
1:1 joins in a single query).
StorageSQL in turn still uses lower level calls to StorageSQLmetabase
(or soon StorageSQLcreole).
Queries are named using a fixed prefix (the action: set,get,del or misc)
and some fixed or custom names in a dot separated path-like name
(get.multiple, misc.count_result). Queries are either static (from a
file) or dynamic (generated by user code).
Relation properties will have four states: null means nothing is linked,
'UNKNOWN_VALUE' means relation is not loaded, a single value or an array
of values are the fk, obj or array of obj are really loaded related
entities. Values of 'load' attrib in edf can be none or fk or all.
I added EntityInfo which is an object cache for edf and queries.
that will later be extended to add user custom query generation.