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
> 
> 


Reply via email to