openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: TransferFieldManager#fetchObjectField
Date Mon, 23 Feb 2015 20:13:11 GMT
The fun thing is that fetchString doesn’t set val = null.
But this could basically create the very same mem issues…

LieGrue,
strub

> Am 21.02.2015 um 15:47 schrieb Rick Curtis <curtisr7@gmail.com>:
> 
>> I've checked the history of this very code and it seems to originate from
> Kodo already... So I am a bit reluctant to touch it ;)
> I noticed the same thing...
> 
> On Fri, Feb 20, 2015 at 11:35 AM, Mark Struberg <struberg@yahoo.de> wrote:
> 
>> My current problem is that we try to use the InverseManager with
>> action==Exception (so only check if the bidirectional relations are
>> properly set in our code).
>> 
>> The use case is the following
>> 
>> Partner has a 1:n Customer
>> 
>> p1.addCustomer(customer1).
>> 
>> in a later request
>> 
>> p1.removeCustomer(customer1);
>> 
>> and add it to ANOTHER partner
>> p2.addCustomer(customer1).
>> 
>> The partnerId in customer1 gets properly updated.
>> 
>> What happens is that the InverseManager invokes
>> SingleFieldManager#fetchObjectField(fmd.getIndex()); to get the oldValue of
>> the field (and does checks on it).
>> And this fetchObjectField call actualle ERASES the internal val in the
>> SingleFieldManager.
>> 
>> This makes OpenJPA later blow up as this field is not nullable...
>> I've checked the history of this very code and it seems to originate from
>> Kodo already...
>> So I am a bit reluctant to touch it ;)
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 20.02.2015 um 18:29 schrieb Rick Curtis <curtisr7@gmail.com>:
>>> 
>>> I don't have an answer as to why we null the reference out. Can I get a
>>> stacktrace for a bit of context?
>>> 
>>> On Fri, Feb 20, 2015 at 10:02 AM, Mark Struberg <struberg@yahoo.de>
>> wrote:
>>> 
>>>> Does anyone have a clue or remember why the
>>>> TransferFieldManager#fetchObjectField sets the val to null after
>> returning
>>>> it?
>>>> 
>>>> 
>>>> The reason why I ask is that this currently creates an issue in the
>>>> InverseManager for me.
>>>> 
>>>> In InverseManager#storeField line 332 this 'destroys' the field sm as
>> the
>>>> val of it is null afterwards. And this subsequently creates an
>>>> InvalidStateException in SingleFieldManager#preFlush line 567.
>>>> 
>>>> 
>>>> Does anyone remember something about that?
>>>> 
>>>> LieGrue,
>>>> strub
>>> 
>>> 
>>> 
>>> 
>>> --
>>> *Rick Curtis*
>> 
>> 
> 
> 
> -- 
> *Rick Curtis*


Mime
View raw message