> But this could basically create the very same mem issues...
I haven't thought very long / hard about this one... but I struggle to come
up with a reason where this could/would cause some sort of a memory leak.
On Mon, Feb 23, 2015 at 2:13 PM, Mark Struberg wrote:
> The fun thing is that fetchS
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 :
>
>> I've checked the history of this very code and it seems to originate from
> Kodo already... So I am a bit relucta
> 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 wrote:
> My current problem is that we try to use the InverseManager with
> action==Excep
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);
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 wrote:
> Does anyone have a clue or remember why the
> TransferFieldManager#fetchObjectField sets the val to null after returning
> it?
>
>
> T
