Hello gents, >> Q : EntityStore versus IndexingStore >> >> Ok, I think I get the concept behind this two storage techniques. The >> questions is >> when to use what and eventually it makes sence to use them in a combination. > > No. Indexing is integrated to UnitOfWork's management of Entities, and > is not intended for explicit/direct use. > > The Indexing hooks into the UnitOfWork Callback mechanism, and the > implementation is allowed to be eventually consistent.
Ok, I take a look into the SQL EntityStore and SQLIndexing source code and it looks like that the Entity State changes are propagated using the notifyChanges() call (StateChangeListener Impl). Means then when a Entity is stored in the EntityStore (using uow.complete() ) it is immediately (and in one transaction ?) "stored" also in the indexing schema ? Or there are two transactions, one for the EntityStore and one for the SQLIndexing so that therefore they might be eventually consistent ? >> Q : Domain Model Versioning and/or Migration > > Indexing == Drop it, reindex. > Well, this might work for smaller datasets but for large databases I would avoid to reindex, means move data from the storage, processes it somehow, and then write it back in another representation that fits the indexing requirements. But I think the lazy-migration approach sounds interesting - will give it a try.. Thank you guys, Jiri 2012/10/9 Niclas Hedhman <[email protected]>: > Since it is late, I will be brief and revisit this tomorrow... > > On Tue, Oct 9, 2012 at 9:14 PM, Jiri Jetmar <[email protected]> wrote: >> as mentioned I spent some days working on our domain model using the >> Qi4J/DCI approach. >> I;m still very impressed how lightweight the qi4j "way" behaves - in >> comparison with e.g. JPA with all the needed annotations, >> configurations, etc.. It is incredible easy to add/modify/refactor an >> Entity or Attribute, and use it immediately in the code... Wow.. :) > > Thanks. That is what we think too. Going back is really painful... > >> Q: How to express ManyToMany associations. Something like this : >> >> interface Group { >> >> ManyAssociation<User> users(); >> >> } >> >> interface User { >> >> ManyAssociation<Group> groups(); >> >> } > > Well, except that you should avoid, I don't think there is anything in > Qi4j preventing you from doing exactly what you have done above. Since > under the hood, the (Many)Association is simply the Entity's Identity > stored, you should be able to simply; > > 1. Create the User, > 2. Create the Group, > 3. Add User to Group.users(); > 4. Add Group to User.groups(); > 5. complete(); > > IF that doesn't work off the bat, you might need to do it in two > steps, and you might need @UseDefaults annotation. > What you can not do is put an @Aggregated on both. > >> Q : EntityStore versus IndexingStore >> >> Ok, I think I get the concept behind this two storage techniques. The >> questions is >> when to use what and eventually it makes sence to use them in a combination. > > No. Indexing is integrated to UnitOfWork's management of Entities, and > is not intended for explicit/direct use. > > The Indexing hooks into the UnitOfWork Callback mechanism, and the > implementation is allowed to be eventually consistent. > >> Q : SQL Performance >> The IndexingSQL Store is producing a highly "obfuscated" schema. As long as >> one >> do not need to work on this schema, e.g. to build some views this does >> not matter. >> Evtl. it would be possible to use instead of qname_number the names of >> the entity and attributes ? Like person_age (entityname_attributename >> ). Another question is the performance. Are there any experience how >> postgresql behaves when there is an entity with e.g. 30 attributes >> and one is reading them out and as a consequence the SQL query will >> contain many JOIN statements ? > > I don't know if there are any hard fast numbers. Indexing/Query is > probably not your primary access pattern, and queries are relatively > rare compared to the Store/Retrieve functionality. Very often, you can > replace your typical SQL queries with Associations. > > And queries in Qi4j doesn't intend to rebuild the Entity, only to > produce an Identity which is then used on the Entity Store. Therefor, > by marking properties @Queryable(false) on everything you don't want > to query, you can achieve great improvements in indexing speed. > > >> Q: Custom Datatypes >> As we are doing some spatial queries it is required to i.) add spatial >> datatypes (e.g. point) >> and ii.) it is further needed that the generated SQL is supporting the >> spatial extension (Postgis). These are basically additional (SQL) >> functions that are used in the spatial query statement. >> What would be the best approach to add the above features ? > > Implement your own Indexing/Query system?? > Forking an existing implementation is probably the best choice, since > indexing/query implementations are magnitude more complex than an > entity store. > >> Q : Domain Model Versioning and/or Migration >> >> To extend/modify the Domain Model using Qi4J is extremely easy and >> lightweight - probably too >> easy.. :-) During development this makes sense, but when there is >> already one productive database >> what is the strategy for versioning and for migration from one version >> to another ? When e.g. >> one attribute is removed the corresponding qname_number table (in the >> SQL Indexing case) has >> to be removed as well, or when e.g. the datatype of that attribute is >> changed the old data must >> be migrated. Or the domain model contains a versioning concept >> where "old" data are never migrated to new versions but for each >> entity multiple versions are available. I;m not sure about all the >> consequences, but would be interesting what is your >> opinion/advice on this topic from you guys. > > Indexing == Drop it, reindex. > > Entity Store; You have perhaps seen that there is a "Migration > Extension", which allows you to capture the refactorings that has > happened on the domain model, and Qi4j keeps the model versions of the > stored entitiy, and if it comes across an older one, it will ask your > migration rules to convert the individual entity. So the conversion > happens in runtime. I haven't touched that code for quite a while, so > I can't recall the exact possibilities with it. But it has been > considered... > And this is an area which probably can be improved a lot. > > > Cheers > -- > Niclas Hedhman, Software Developer > 河南南路555弄15号1901室。 > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/6a2pl4j > I relax here; http://tinyurl.com/2cgsug > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
