Doesn't matter - it works against all stable branches (1.2, 2.0) and
trunk (3.0). The one I quoted is done against the trunk. When I
applied it against 1.2 I had to manually change "apache" to
"objectstyle" in the file name. There was one failed piece that you
can safely ignore.
Also I am planning to commit it on 1.2 branch sometime today.
Andrus
On Dec 21, 2006, at 11:35 AM, Florian.Esk..i-de.com wrote:
> Hi Andrus,
>
> is your patch based on a 1.2.1 or on a 1.2 version of cayenne.
>
> Because we will it insert this version in our local maven
> repository and we
> will not wait for a official release.
>
>
> Thanks
> Florian
>
>
>
>
>
> Andrus Adamchik
> <andru..bjectsty
>
> le.org> An
> cayenne-
> use..ncubator.apache.org
> 21.12.2006
> 09:39 Kopie
>
> T
> hema
> Bitte antworten Re: Loosing references to
> foreign
> an objects -> update will fail
> cayenne-use..ncu
> bator.apache.org
>
>
>
>
>
>
>
>
> Good to know that it worked - I will commit it to 1.2 and 2.0
> branches. Here is the contents of the patch:
>
> http://tinyurl.com/sz7fw
>
> In short it prevents incomplete snapshots (those that contain only PK
> columns and no other data) from being stored in the shared cache.
> There were other safeguards against it, but obviously they weren't
> working under certain circumstances.
>
> Andrus
>
>
> On Dec 21, 2006, at 10:15 AM, Florian.Esk..i-de.com wrote:
>
>> Hi Andrus,
>>
>> so your patched jar works for us in this case. The error doesn't
>> occure any
>> more.
>>
>> So first question.
>>
>> What do you have changed, because we also tried the 1.2.1 version?
>>
>> Thanks florian
>>
>>
>>
>>
>>
>> Andrus Adamchik
>> <andru..bjectsty
>>
>> le.org> An
>> cayenne-
>> use..ncubator.apache.org
>> 21.12.2006
>> 07:38 Kopie
>>
>>
>> T
>> hema
>> Bitte antworten Re: Loosing references to
>> foreign
>> an objects -> update will fail
>> cayenne-use..ncu
>> bator.apache.org
>>
>>
>>
>>
>>
>>
>>
>>
>> I wonder if that's another consequence of this bug:
>>
>> http://issues.apache.org/cayenne/browse/CAY-724
>>
>> I implemented a fix that works in my application, but I still don't
>> fully understand the underlying cause of it. Still it looks like a
>> suspect here too. Anyways, here is a patched 1.2 jar file that I
>> uploaded here:
>>
>> http://people.apache.org/~aadamchik/cayenne-1.2-patchCAY-724/
>>
>> Try that first and let me know if it worked. If it doesn't, next
>> thing to check is the value of "Max Number of Objects" for the
>> DataDomain in the Modeler (default is 10000). You may try to increase
>> it to something higher.
>>
>> Andrus
>>
>>
>>
>> On Dec 20, 2006, at 5:52 PM, Florian.Esk..i-de.com wrote:
>>> Hallo,
>>>
>>> in our application we loose sometimes the reference to a mandatory
>>> foreign
>>> object (not null, foreign key)
>>>
>>> Our object relation are
>>>
>>> Export Container -> products
>>> product -> client
>>> product -> image
>>> product -> state
>>>
>>> The problem occurs in our exporter process. It works like
>>>
>>> Begin Transaction
>>> Select all products that are in the correct state
>>> Create the export container
>>> export all product information including the image blob to file
>>> (read
>>> the objects into the memory)
>>> change the export container content
>>> for each product create the following state of the process
>>> (update of
>>> the product row and create a new state row)
>>> commit Transaction
>>>
>>> During the commit some of the products have no reference to a client
>>> object. => Update will fail because no mandatory object reference
>>> exist.
>>> (org.objectstyle.cayenne.validation.ValidatiionException
>>> Product.client:
>>> "client" is required.)
>>> The database contains the correct client relation.
>>> So it will run correct if we reduce the max. exported products to
>>> 100. But
>>> for a other run with other data we exported 500 products per export
>>> run.
>>>
>>> Also we have attached to the running process and so we see no memory
>>> problem, because it occure if we have around 300 MB free memory in
>>> the jvm.
>>>
>>> For a test run we also changed the implementation. So step 6 will
>>> also make
>>> a commit for each product update :-(.
>>> The result is that we can export the first 480 products, than we
>>> got the
>>> error. Than we have additional product in the correct state to
>>> export. So
>>> we will export in the example 180 and after 176 we got an additonal
>>> error.
>>> Afterwards we export the last 4 without a problem.
>>>
>>> So for us it seems that we loose during the processing the
>>> references of
>>> some of out products. The corrupt products hat the persistent
>>> state 3
>>> (Commited) and after the change state 4 (Modified). The persistent
>>> state
>>> seems for us okay.
>>>
>>> Our Environment:
>>> Windows XP
>>> Oracle
>>> Cayenne 1.2
>>> Jboss
>>> Jdk 1.5.0.5
>>>
>>> thanks
>>>
>>> florian
>>>
>>>
>>
>>
>>
>>
>
>
>
>
This archive was generated by hypermail 2.0.0 : Thu Dec 21 2006 - 04:48:41 EST