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 <curti...@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 <strub...@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*
