Le mardi 15 décembre 2009 05:11:59, Niclas Hedhman a écrit : > First choice is exactly what the EntityStore SPI is all about. I think > you will get the most bang for the buck, so to speak, by going that > route. You can either put each store in the module of the domain > layer, but you can also utilize Layers, but that depends a lot on your > overall model. Ok, so my understanding was not plain wrong :)
> Finally, if you plead really nicely, we could enable a > planned feature a little early, which allows each entity to have a > declared EntityStore. At the moment, all entities in the same Module > share an EntityStore. >From the implementation POV I'd prefer to have several small and simple >EntityStore impls over having a big complicated one and my model allows me to have clear boundaries so no need to hurry. > As for Indexing/Querying; The whole point in Qi4j is that we separate > the storage from indexing (like the world wide web does), to enable > easier storage implementations and cross storage searches. Yes it > means that more space is 'wasted', but is rarely an issue these days. > Another upside is that the index can be tossed and recreated at any > time, so even if you already have data in your stores, if you > implement the EntityStore SPI correctly, the Indexer can be told to do > a reindex of that data. I see, so if I apply what you suggest to my use case I'll setup an in-memory index populated on application start. That would work. > There is an additional case, where external systems update the same > store, and for that I recommend you to "NOT DO IT". The biggest reason > is that of responsibility and audit... "Who did it?" when something > went wrong. Instead, I like the messaging approach with 'local store'. > This makes collaboration across projects/systems a lot easier, and one > is not very constrained to "other people's work", which is a major > efficiency inhibitor. Thanks for the feedback Niclas, that's really appreciated. I'm still in exploring phase so I may come back with questions and feedback about my experimentations. Paul _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
