On 2010-12-28 20.55, Niclas Hedhman wrote:
For each StockDividend there are a few hundred streams(), but the
"stream names" are known to the user applications via other means and
many streamNames are shared across many StockDividends.
So, now; How do I get from [StockDividend]+streamname to
[DividendStream] ?? There is no identity to DividendStream known to
external systems other than a sub-entity of StockDividend.
Ok, good, now you have explained the problem so I can understand it.
Progress!
I have covered the the options previously... I came to think of one
more; I can require the domain modelers to create 3 layers instead of
two, where the outermost only deals with 'external' to 'internal'
identity translation, but to me that also feels like big hack to get
around...
This would basically be like getting some identifier, making a query,
and then doing a load of found entities. API-wise this sounds ideal. The
issue you seem to be having is simply that the Query is too slow. Is
that right?
If yes, then caching would seem to solve it. Since this is highly
cacheable data (identities are stable) you can do this as a cache lookup
(external identity->internal identity), and have the cache be persistent
to only have to do it once.
Perhaps you are fortunate enough to be able to move internal
identities to external clients. That choice is sometimes/often not
available, a world of external identities exists, and when they are
compounded from several fields Qi4j can't cope, or at least that is my
assertion.
This is a common case, and it is tempting to use the external identities
as the internal identities. I don't think this is a good idea, but in
the end it's up to you. I would stay away from it as long as possible,
as there are so many examples of projects that have been bitten by this
bug before, and suffered the consequences when the identities turn out
to be "almost-never-changing".
I am bringing up a short-coming that I feel is real, and sense that
you feel it is not real since you leave in a "bounded bubble".
The problem was that you didn't explain what the problem was, and went
straight for the solution to this non-explained-problem. Now you have
explained it, so I can understand what you're trying to accomplish in
the first place. Progress!
As I said, I think even IF I had to do it all myself, I think the
problem still persist, and that the culprit is known as "external
identities".
Ok, so the way *I* would solve this (to avoid external identities
seeping into the internal identity system), is to put those identities
as additional fields on the entities, and then use Queries to find them.
If Queries are too slow, cache them but still use the same API to
actually do it from the code. Then it is clear in the domain what these
identifiers are (as they are in named fields), they can change if they
want to, and we have one way to get from "I want an entity that looks
like this, gimme" (i.e. the Query API), rather than using identity key
creation algos.
Are you sure you still want to do local identities?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
