spring-data-neo4j depth on persistance

169 views
Skip to first unread message

Fredrik Hultin

unread,
Apr 26, 2012, 2:04:22 PM4/26/12
to Neo4j
Hi,
found a funny problem with the spring-data-neo4j (2.1.0.M1), all
objects below are annotated with @NodeEntity:

Load an object:
-- MyObject obj = repo.findAll.single();

The object has a child with a list of grand children on which t we
want to add to:

-- obj.getChild().addChildren(new GrandChild());

and save
-- template.save(obj)
Now the new grand child will NOT be persisted! No error no nothing.

-- template.save(obj.getChild())
Still not working!

However:
-- Child child = obj.getChild();
-- template.save(child);
Saves the children as expected. As it looks like in the code the
getChild() method does some ajp lookups. This is maybe where the child
gets fetched from the store?

I guess this has something to do with the dirty flag of the child
object (to much ajp code for tonight).
What is the expected behavior? From hibernate I would have expected my
full graph to be updated. Is there a way to control the save depth? By
only having one level the spring-data-neo4j becomes a little bit
useless since many object structures are deeper than that so I guess I
am doing something wrong here...

/Fredrik

Peter Neubauer

unread,
Apr 28, 2012, 6:42:25 AM4/28/12
to ne...@googlegroups.com

Michael,
Do you have any input here?

Michael Hunger

unread,
May 7, 2012, 5:37:22 AM5/7/12
to ne...@googlegroups.com
Fredrik,

sorry for the delay :(

Yes transitive cascading persist is not yet supported, so far it hasn't been a problem for users.

The problem with cascading persists is that you not always want that, and then it gets very hairy b/c it has to be configured etc.

Other comments inline.

Am 26.04.2012 um 20:04 schrieb Fredrik Hultin:

> Hi,
> found a funny problem with the spring-data-neo4j (2.1.0.M1), all
> objects below are annotated with @NodeEntity:
>
> Load an object:
> -- MyObject obj = repo.findAll.single();
What does your repo look like.

>
> The object has a child with a list of grand children on which t we
> want to add to:
this is a cascading persist
>
> -- obj.getChild().addChildren(new GrandChild());
>
> and save
> -- template.save(obj)
you would have to save the child that should work
> Now the new grand child will NOT be persisted! No error no nothing.

ok, right there should be an notification for the user that it only works up to a certain level. I add a test for that to SDN.
>
> -- template.save(obj.getChild())
> Still not working!

in general with the advanced mapping there should be no save necessary as the change is persisted directly to the graph (not yet committed though)
- this should work, could you please show your implementations for the 3 objects ? (MyObject, Child and GrandChild ?) best to share a demo project that exhibits this behavior?
>
> However:
> -- Child child = obj.getChild();
> -- template.save(child);
> Saves the children as expected. As it looks like in the code the
> getChild() method does some ajp lookups. This is maybe where the child
> gets fetched from the store?

Yes it fetches the data for the child from the store and creates a java object for it, so it is probably not the _same_ object a the one you've got before!
Relationship-collections (or single values) are always fetched from the graph to represent the correct state
>
> I guess this has something to do with the dirty flag of the child
> object (to much ajp code for tonight).

Hmm good question, as the grandchild is newly created it shouldn't have a dirty flag (just no assigned state) and the child has a dirty flag as it got changed by adding the grandchild.

> What is the expected behavior? From hibernate I would have expected my
> full graph to be updated. Is there a way to control the save depth? By
> only having one level the spring-data-neo4j becomes a little bit
> useless since many object structures are deeper than that so I guess I
> am doing something wrong here...

The advanced mapping directly interacts with the graph it doesn't have the detach/attach behavior inside of a transaction.
I ASSUME that your operations all happen within a transactional method.

Cheers

Michael
>
> /Fredrik
>

Reply all
Reply to author
Forward
0 new messages