Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cayenne-user@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <452A5213.2060707@najdi.si>
References: <446E732D.5040901@pfrog.com>
 <d487eb8e0605192331i3a114024t1a3f49a48378c1e6@mail.gmail.com>
 <71E3857E-CC22-456C-9813-DEE96ACC8A6E@gmail.com>
 <9813CBF2-1A71-4BDF-BC95-C3504631022D@objectstyle.org>
 <452A5213.2060707@najdi.si>
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Message-Id: <EDD395A4-4E4C-4920-AAD3-D32EC9E74490@objectstyle.org>
Content-Transfer-Encoding: quoted-printable
From: Andrus Adamchik <andrus@objectstyle.org>
Subject: Re: Parent/Child Insert ordering (was: Caching problem?)
Date: Tue, 10 Oct 2006 20:57:09 -0400
To: cayenne-user@incubator.apache.org

Good question :-) Andriy, our math geek, is no longer with us. I =20
don't recall the details (need to dig through Ashwood I guess), but =20
simple parent/child relationships within the same table used to work =20
afaik... We may think of smarter strategies to resolve the cycles =20
(such as a chain of insert/update queries in the same transaction)... =20=

I don't think this will happen soon though.

Andrus


On Oct 9, 2006, at 9:43 AM, Borut Bol=C4=8Dina wrote:
> Hi,
>
> in API docs for org.objectstyle.cayenne.map.AshwoodEntitySorter it =20
> says:
> "...Presently it works for acyclic database schemas with possible =20
> multi-reflexive tables. The class uses topological sorting from the =20=

> Ashwood library."
> What are multi-reflexive tables? I guess not every reflexive =20
> relationship is cyclic. If db row "points" to the same db row then =20
> it would be cyclic (for example - someone is his/her own manager), =20
> otherwise just reflexive. Is this correct?
>
> -Borut
>
> On 21.5.2006 19:24, Andrus Adamchik wrote:
>> Cayenne handles correct ordering of operations automatically, =20
>> based on dependencies derived from relationships.The algorithm has =20=

>> a few limitations though. It can't handle cycles (when Entity A =20
>> depends on Entity B, but also Entity B depends on Entity A). This =20
>> probably also includes entities that have relationships to the =20
>> same entity (I assume this is the case the original post was =20
>> 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 =20
>> DEFERRED (supported by Postgres 8.*)
>> 3. Set a custom org.objectstyle.cayenne.map.EntitySorter on the =20
>> DataNode.
>>
>> Andrus
>>
>>
>> On May 20, 2006, at 3:00 AM, Marcin Skladaniec wrote:
>>
>>> Hm. Strange. I do really complex commits, sometimes 7 or more =20
>>> related records (I mean 7 levels of relationship, not seven =20
>>> entities), related by many-to-many many-to-one relationships and =20
>>> never get those problems. And it doesn't matter if the records =20
>>> are new or old. Could you describe how you are creating objects =20
>>> 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 <jdevries@pfrog.com> wrote:
>>>>> I don't know if it is related or not, but I've also had =20
>>>>> problems in the
>>>>> past when I try to create a new parent and several child =20
>>>>> objects related
>>>>> to that parent all at once and then try to commit.  The problem =20=

>>>>> looks
>>>>> like Cayenne is INSERTing the child records into the database =20
>>>>> first,
>>>>> before the parent record, and the database complains that the =20
>>>>> 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 =20
>>>>> get the
>>>>> error from PostgreSQL).  To get around it I just committed the =20
>>>>> 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 =20
>>>> imagine
>>>> everything that's going on under the hood of the operation that =20
>>>> 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 =20
>>>> be an
>>>> atomic transaction. It'd also make the framework a lot more =20
>>>> flexible,
>>>> e.g. enabling the user to have long inter-commit sessions with =20
>>>> complex
>>>> data updates, if the user so desires.
>>>>
>>>> t.n.a.
>>>
>>>
>>
>
> --=20
> <blog-logo.gif>
>
> --
> Naklju=C4=8Dna izjava tedna iz tednika Mladina: