On Thu, May 22, 2008 at 2:50 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Thursday 22 May 2008 14:03, Tobias Ivarsson wrote: > > > 1. Set up. To initiate the Neo4J bindings you will need to set up Qi4J to > > use the Neo4J services, these are at the moment: > > module.addServices( > > NeoEntityStoreService.class, > > NeoCoreService.class, > > DirectEntityStateFactory.class, > > IndirectEntityStateFactory.class, > > NeoIdentityService.class > > ); > > This might change somewhat as development progresses. I have been > > thinking of adding a utility method somewhere to do the appropriate > setup, > > regardless to how the internal implementation changes. > > We normally recommend that you prepare one or more Assemblers, which I as a > developer just throw into my bootstrap, without knowing the details. Sounds exactly like what I want to do. Is there an example of how to provide the Assemblers that I can look at? (If there isn't I'll just provide an enum of Assemblers) > > > > * Also coming soon is the ability to reference entities stored in > another > > EntityStore. > > Uhhh, what??? An EntityStore doesn't really know of Entities and not about > other EntityStores either. You just need to keep the QualifiedIdentity in > the > Associations and return those upwards. What am I missing in your statement? (As Rickard pointed out while I was writing this: ) True, the EntityStore does not know about Entities, but it does know which QualifiedIdentities are stored in this EntityStore, and which are stored somewhere else. And at the moment I haven't implemented the indexing that is needed to store QualifiedIdentities that are not generated by the ID-generator I have supplied in this package. When this is in place id-generation will be completely orthogonal to storage, and before this is in place, we can only store Entities represented by QIDs generated by this ID-generator. Even after this is in place the supplied ID-generator will be a fast-track since it uses native id's for which we have lightning fast lookups :) Actually now that you mention it, I never really like that part of the design, that design decision was just so long ago that I had forgotten that I didn't like it. I'll have to bubble fixing that to the top of my TODO-list. I'll get into more detail on the question of transactions later. I'll need to think about it for a while first. I do agree with you that preferably the programmer should never have to worry about transactions, and only deal with UoWs. But we are not quite there yet, and this is a solution that works now. It is nice to not have to copy all the state out of the EntityStore, but be able to manipulate it through EntityState objects that are just thin wrappers around primitive Storage objects (as is the case with the Neo EntityStore). It is also nice to be able to revert changes that are canceled by rolling back the transaction. To be able to do this, the transaction needs to be kept open for the duration of the UoW. Then there is the problem of transaction vs UoW mismatch. Transactions are, and whould be, short in time. While an UoW can (but does not have to) span over a long duration of time. An UoW could for example correspond to a user working with a form, in the middle of working the user takes a lunch break and is gone for an hour, with the form open. An with the UoW concept we want that to work. You would not, however, want to keep an transaction open for that duration. This is what the implementation I am working on is for, and in that implementation the state is copied and then written back. One positive thing about the EntityStore implementation that I have committed is that since it doesn't copy the entire state from the underlying representation. Therefore it excels in use cases where you want to make small changes to large (or even huge) data sets. Imagine Scrooge McDuck wanting to use Qi4j for his coin collection. He is very loving of his coins, so each coin is represented by a separate Entity with properties for age, damages, where it was earned and whatever. Scrooge McDuck has billions of coins. In this application Scrooge also has an Entity representing his vault, this entity holds a collection of all the coins in the vault. Now Scrooge wants to add todays shipment of a few thousand coins to the vault. The entire representation of the vault with all the billions of coins is impossible to read into main memory. Holding todays shipment however is no problem. This implementation solves this perfectly. Since it doesn't have to copy the entire existing state of the vault to memory it only needs enough memory to store the new shipment of coins before the transaction is committed. I believe that use cases such as this (even if this particular example is quite silly) exist. Which is why I want to be able to work with my Entities in this way. I do agree with you though, and I repeat this, that it would be better if this was all transparent to the programmer, we just haven't solved that problem yet. But when we do, oh what a beautiful world it will be! -- Tobias Ivarsson <[EMAIL PROTECTED]> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
