Hello gents,
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.. :)
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 ?
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).
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;m planing to do such a test by my
self on several TBs of data, but would be
nice if there are already some experience on that topic.
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 ?
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.
Thank you.
Cheers,
Jiri
2012/10/2 Stanislav Muhametsin <[email protected]>:
> Quoting Niclas Hedhman <[email protected]>:
>
>> On Tue, Oct 2, 2012 at 5:15 PM, Stanislav Muhametsin
>> <[email protected]> wrote:
>>
>>> Yes, except it takes it further - one *table* for each full-qualified
>>> property/asso name. The collection value types complexify it a bit but
>>> not
>>> extremely much. Thus we can store each property/asso of the entity
>>> without
>>> the need to fill rows with empty values. Of course, the complexity then
>>> grows. And there is a schema - it contains tables and their constraints
>>> for
>>> all properties/assos of all entity types used in whole Qi4j application.
>>
>>
>> There is never a need to have one table per prop/assoc, other than a
>> convenient implementation detail for the entitystore author. The
>> proper granularity should be my suggestion 3, one table per mixin type
>> with one column per prop/assoc.
>
>
> I was talking about indexing, not entitystore. The problem with one table
> per mixin type are ManyAssociations and Properties with collection types.
> Those would need to be unwound, losing the data integrity and making queries
> far more complex, by needing to use regexes etc.
>
> For entitystore, there the suggesion 3 might work. I guess it is better from
> storing full composite state into one column - then you can add/remove
> entity mixin types more easily, and also having possibility of having
> different mixins for same entity in different applications.
>
>
>>> Ah, the ever-lasting dilemma of complexity growth. What happens when you
>>> are
>>> adding features that are extremely hard to solve when built on noSQL
>>> solution? :) If noSQL doesn't solve *all* problems, surely there must
>>> exists
>>> such scenarios (none come to my mind right now tho).
>>
>>
>> Right... The answer; combine. And with that comes things like
>> embracing "No distributed transactions", which requires a different
>> kind of design approach.
>
>
> Mmhh. True, although it's hard to combine things properly, without getting
> bad side-effects from both.
>
>
>
> _______________________________________________
> 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
