Hi, > Am 06.04.2017 um 15:54 schrieb Hilaire <hila...@drgeo.eu>: > > Hi, > > Here is another scenario where I have trouble with Voyage: > > Let's an object A, with an attribute an object Address. > Then I create B, a copy of A. > > Of course the object Address is both an attribute of A and B. (no deep > copy). > > As long as my Voyage repo is running, editing Address from A or B is > doing fine: when editing Address from A, I can see this reflected in B's > Address, as expected. > > Sadly, this Object scheme is lost in the persistency: when I reset the > repo, shutdown it, restart it, to force a full retrieve from the Mongo > repo, object A and B do not share anymore the Address object has it > should be. > > I understand Voyage is not a true really Object Oriented repository, but > is it possible to overcome such limitation? > The Adress object must voyageRoot in order for this to work. If an object is voyageRoot it is kept as identity being a separate object living in a collection that can be referenced. If it is not voyageRoot you store a copy of the object each them because that object gets embedded into the container object.
> One idea will be to have collection of Address, but this really looks > strange to me. > why? > I think Fuel was doing just fine with such scenario, but sadly Fuel is > not reliable between images. > Fuel stores the object graph as it is. It is hard to compare because you cannot search a fuel dump. I think the question is what you need. If it is having a partial graph in memory that has been extracted from the whole graph through query then you have a pretty decent need for a database and a tool like voyage. If you just need to persist you are better off with fuel. And if you need the same to be reliable between two images use STON. > Thanks to read up to here. > You're welcome! :) Norbert > Hilaire > > -- > Dr. Geo > http://drgeo.eu > >
