Quoting Rickard Öberg <[email protected]>:
Can you briefly outline how you did that? What is the strategy?
One EntityStore I am considering is to simply have a key-value table
approach, which would at least enable using an RDBMS as a store,
with transactions and all that. That I think would be useful for
those who can't go the NoSQL route.
Yeah, using RDBMS as entitystore is relatively simple - but performing
queries in sensible manner is hard unless the database table structure
itself supports the structure of entities. Shortly put - the RDBMS
indexing creates a single table for each qualified-name that is
possible to use when using entities, and uses those tables when
performing queries.
My current apporach is the following:
1. At startup of application, the RDBMS-indexing scans for all entity
types, and ALL value composite types that can be used with them.
2. If a schema used in configuration exists, current implementation
drops it, along with any data in it. This is because I haven't had
time to implement algorithm, which would sync database structure with
application entity structure. Obviously, this is an important todo.
3. A mapping-table for entity types, containing id and class name, is
created, and each entity composite type is inserted to it.
4. A mapping-table for used classes, containing id and class name is
created, and each used value composite type and enum type is inserted
to it.
5. A table containing common information about entities is created. It
has primary key, entity type id (from (3)), entity identity, modified
timestamp, entity version, and application version as columns.
6. For each QualifiedName in each entity and value type, except
Identity.identity, a table is created. Table has a name of pattern
qname_<number>, and application contains mapping between each
qualified name and table representing it. Obivously the database
should contain this mapping too, in order to implement algorithm
mentioned in (2). The structure of each table is different whether the
qualified name represents a primitive property, property of value
composite, or a collection of primitive or value composite. If a
qualified name represents a collection, two additional tables are
created (to unwind possible nested collection structure).
The queries are then processed in a similar manner as with RDF. The
pattern is that disjunctions are transformed into SQL union,
conjunctions are SQL intersections, and the rest (or most of it) are
normal SQL conditions in WHERE-clause inside appropriate subquery. The
transformation is a bit complex, and might produce big queries for
complex Qi4j-queries, especially if there is an order by -statement,
but the idea would seem to work on conceptual level. I have no idea
yet as if how quick (read: slow) it will be. But SQL is pretty good
when optimizing things, so even if it is ultra-slow at start, by
creating appropriate indexes, it is possible to speed up things
significally, so I am optimistic in that.
If anyone wants to pick that up, please let us know.
I will have time for this in June at soonest, if no one else wants to do this.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
