Problem with shared column mapping

Question

I have a problem with mapping different fields onto the same column. In most cases Kodo handles it very well but one tough case it does not
Modification references contract N-1 using contract_id field
Contract back references two modifications out of all modification owned by THIS contract (last_modification and executed_modifcation)
when both modifications are not null it works fine since I make sure both fields point to modification owned by the same contract
hovewer when I set one of the fields (executed_modifcation) to null (after it was not null) Kodo attempts to set not only executed_modifcation field to null but contract_id as well. Which obviously not desired
I understand that it is a pretty hard corner case. Do you think you can handle it or it is a dead end?
Attached are my files

Answer 1

Abe,
I fully agree with your analysis. In my case we can use precedence of direct
mappings over reference mapping in null situation.
However as you noted, there are cases when we have only references and so
you can not say which mapping is more important. However since we are
resolving NULL issue here, I am not sure we need to know precedence of
references - not null case should always take precedence. In other words:
priority 1: direct mapping
priority 2: not null reference
priority 3: null reference
Of course all three cases are subject rule of not changing value of shared
column
"Abe White" <[email protected]> wrote in message
news:[email protected]...
I admit that I didn't go through all your metadata, but I do believe that
3.0 final will handle this case. My plan is to implement updates such
that direct field mappings always take precedence over foreign key
mappings.
Let's say column CONTRACT_ID is used by int field contractId and is
also used by field lastModification as part of an FK to a Modification
instance (which I believe is close to your mapping). Because contractId
is a simple field rather than a foreign key, Kodo will give it the final
say on nulling/defaulting the CONTRACT_ID column. So if you null the
lasetModification field, CONTRACT_ID will retain the value of the
contractId field. Any non-null value of the lastModification field will
stilly have to jive with the contractId field, though, or else we'll
throw an exception like we do currently when you try to set 1 column to
multiple values.
I believe this solves the common case of shared
columns between direct mappings and FK mappings. There are other cases
in which multiple FK mappings overlap on certain columns, and this does
not solve nulling problems in those instances. However, I think those
cases are very rare and not worth the effort. Correct me if I'm wrong
and your situation actually is one of sharing columns between multiple
FKs and no primitives after all.