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
