Jiri Jetmar a écrit :
Hello gents,
Hey,
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.. :)
Yeah, and once you get used to, it it's pretty unpleasant to go back to
JPA & other ORMs :-)
Nevertheless I have some questions that I could not answer by my self
or by looking
to the samples and test source code. Would be nice guys if you can take a look
on these questions..
Q: How to express ManyToMany associations. Something like this :
interface Group {
ManyAssociation<User> users();
}
interface User {
ManyAssociation<Group> groups();
}
The Group Entity can have multiple Users and the User itself can be associated
with many Groups. Both associations are required and I want to create
both Entities
in one UnitOfWork and hence in one Transaction. Do I need something
like a cardinality
helper Entity like "GroupToUserManyToMany" that maps the User and Group ?
You can either do like Stanislav suggested, ie. direct access on one
side of the relationship and query when you need to navigate the other
way around. Or you could use a bidirectionnal relationship but it's your
application code responsibility to maintain its state, ie. to add/remove
users/groups to/from users/groups.
Yes, another approach would be to introduce a UserGroupAssignment entity
in the middle.
Your mileage may vary depending on use cases needed by your domain.
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.
Using CQRS it would be possible to use the EntityStore as a
transactional storage and the IndexingStore as read-only storage for
query/search operations. The replication between this two stores can
be done by using domain events. That means also that IndexingStore
would
be eventually consistent (assuming that the sourced domain events are
not transactional).
Would it be the right approach ? This strategy has also the advantage
that the write and the
read models does not need to use the same underlying storage
techniques. The write (transactional) store can use SQL and the read
(query) model something else (if required).
To paraphrase Stanislav, you should not bother as Entities are persisted
in the closest visible EntityStore and, if assembled, a
StateChangeListener (one part of Indexing) will automatically update the
index for you to query.
There are numbers of EntityStore extensions available and three usable
Indexing extensions (RDF, SQL and ElasticSearch) for you to choose from.
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.
The 'migration' and 'reindexer' should help you in this matter. Sadly
they are not documented yet but their unit tests and source code should
get you started.
Thank you.
Cheers,
Jiri
Hope this helps.
Cheers
/Paul
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
