On Wed, Dec 29, 2010 at 10:47 AM, Rickard Öberg <[email protected]> wrote: > 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?
I think that every concept you describe is a 'work-around' to "give me the current [left-front-tyre]" concept. But I think that you triggered enough thinking... I am actually not interested in "local identities" but "local identity references". If we go back to the Car and Tyre. [left front tyre] is a local identity reference only valid in the Car context. The identity of the Tyre doesn't change, it follows the Tyre. What I called 'local identity' is actually the reference, and for the simple associations, this already exist; Association<Tyre> leftFrontTyre(); So, I guess I am actually wanting is a dynamic entity reference system, type-safe of course. And we have touched on it many times in the past, but never managed to nail it. So, I think that time has come. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
