Object relationship is not correctly updated

[Dirk Vranckaert]

Hey,

I have a very complex sync logic where something goes wrong.

I  have two kind of objects that I persist using TWIG:

1. Task
2. TimeRegistration

The TimeRegistration object has a reference to a Task.

So what I do first: create some tasks in the database, for example Task A and Task B

Then I create a new TimeRegistration in the database linked to Task A. So far so good.

But then it should be possible to link the time registration to a different project. So I change that time registration to be linked to Task B.

I do change the task to Task B. I persist. After the transaction commits I can retrieve the time registration and if I check the task it is Task B.

But then in a new http-request I execute a new sync process. At a certain time I read the same TimeRegistration again and check it's task and it seems to be Task A.

Weird huh...?!

Together with changing the task on TimeRegistration I also change a date-field. In the checks I do after the update the date-field is always correct.

Ever more weird, huh... ?!

I don't get it, but for some reason the relation is not updated...

This is the mapping:

@Entity(kind="timeRegistration")

public class TimeRegistration {

@GaeKey private Key key;

@Index private Date startTime;

@Index private Date endTime;

private String comment;

private String flags;

@Activate @Parent private Task task;

        // Getters and setters...

}

@Entity(kind="task")

public class Task implements Cloneable {

@GaeKey private Key key;

        // Some other fields

        // Getters and setters...

}

[Dirk Vranckaert]

BTW: I also have this when playing with other entities. As long as I change parameters everything is fine, when I start to change object relationships they don't come through...

Op donderdag 16 mei 2013 13:36:43 UTC+2 schreef Dirk Vranckaert het volgende:

[John Patterson]

A very brief scan of your problem and the parent-child relationship might be causing your problem.  changing parent also changes the Key of the child.  It also does not delete the original child.  The correct logic would be to delete the child, copy the child (a new instance) and put it in the new parent, update the parent (which will also store the new child copy)

--
You received this message because you are subscribed to the Google Groups "twig-persist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to twig-persist...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dirk Vranckaert]

I think the problem might be bigger...

The situtation I explained here is very simple. But the next case might (and does) happen:

A1 -> B1 -> C1 (so it's parent is B, B's parent is A).

A1 -> B1 -> C2

A1 -> B2 -> C3

So C will always be one object... But I can change C1 his parent to B2 for example. I could also change B1 his parent to A2...

So that would mean I would have to reconstruct the entire tree all the time... That is:

1. time consuming

2. DB operation consuming

3. Not transparent at all...

Is this a GAE limitation or is it twig-persist?

And is there another way to work around it?

Kr,

Dirk

Op vrijdag 17 mei 2013 02:47:10 UTC+2 schreef John Patterson het volgende: