Going back and looking at my code, I see that a two step commit is fine
in this particular case since the initially committed items can stand on
their own without any inconsistencies. I'll try setting the INITIALLY
DEFERRED and DEFERRABLE constraints anyway to see what happens.
Andrus Adamchik wrote:
> Cayenne handles correct ordering of operations automatically, based on
> dependencies derived from relationships.The algorithm has a few
> limitations though. It can't handle cycles (when Entity A depends on
> Entity B, but also Entity B depends on Entity A). This probably also
> includes entities that have relationships to the same entity (I assume
> this is the case the original post was referring to).
>
> There are few solutions:
>
> 1. (a workaround, rather than a solution) Do commit in two steps.
> 2. Define FK constraints in question as DEFERRABLE and INITIALLY
> DEFERRED (supported by Postgres 8.*)
> 3. Set a custom org.objectstyle.cayenne.map.EntitySorter on the DataNode.
>
> Andrus
>
>
> On May 20, 2006, at 3:00 AM, Marcin Skladaniec wrote:
>
>> Hm. Strange. I do really complex commits, sometimes 7 or more related
>> records (I mean 7 levels of relationship, not seven entities),
>> related by many-to-many many-to-one relationships and never get those
>> problems. And it doesn't matter if the records are new or old. Could
>> you describe how you are creating objects and how do you commit them ?
>>
>> Regards
>> Marcin
>>
>> On 20/05/2006, at 4:31 PM, Tomi NA wrote:
>>
>>> On 5/20/06, Jeff de Vries <jdevrie..frog.com> wrote:
>>>> I don't know if it is related or not, but I've also had problems in
>>>> the
>>>> past when I try to create a new parent and several child objects
>>>> related
>>>> to that parent all at once and then try to commit. The problem looks
>>>> like Cayenne is INSERTing the child records into the database first,
>>>> before the parent record, and the database complains that the children
>>>> have an invalid foreign key (and, yes, I have the ON UPDATE and ON
>>>> DELETE rules for the foreign key set to DO NOTHING and I still get the
>>>> error from PostgreSQL). To get around it I just committed the parent
>>>> first, then committed all the children.
>>>
>>> I had the same problem, IIRC: I was very surprised that cayenne
>>> couldn't handle such a commit, although truth be told, I can't imagine
>>> everything that's going on under the hood of the operation that would
>>> make implementing this feature difficult.
>>> I would certainly love to see this fixed (if at all possible) as I
>>> wasn't to happy to have to commit in the middle of what had to be an
>>> atomic transaction. It'd also make the framework a lot more flexible,
>>> e.g. enabling the user to have long inter-commit sessions with complex
>>> data updates, if the user so desires.
>>>
>>> t.n.a.
>>
>>
>
This archive was generated by hypermail 2.0.0 : Sun May 21 2006 - 15:13:11 EDT