Does MappedOneToManyBase.remove behave as intended?

[Florian Hars]

As far as I read the source, if I call remove(n) or update(n, elem) the
element that used to be at that position gets unowned and removed from the
_delegate list held in memory, but the change is never written to the
database if I only save the parent element, so the next time it is loaded
from the database, the removed element will pop back into the list of
children unless I actively save or delete the child element after removing it.

Is that the intended behaviour or should the save method of MappedOneToManyBase
be more like the one of Owned, except that it calls unowned foreach {_.save} ?
But even that may lead to inconsistencies if I remove a child from object A,
add it as a child to object B, and then save A but discard the changes to B.
(This might be the case for the current implementation of Owned, too).

And if it is intended, the clear() method can't work in its current form.

And what happens if I call OneToMany.delete_! ? Doesn't it leave all the
foreign key references of the child entities that aren't defined as Cascade
dangling?

- Florian.
--
#!/bin/sh -
set - `type -p $0` 'tr [a-m][n-z]RUXJAKBOZ [n-z][a-m]EH$W/@OBM' fu XUBZRA.fvt\
angher echo;while [ "$5" != "" ];do shift;done;$4 "gbhpu $3;fraqznvy sKunef.q\
r<$3&&frq -a -rc "`$4 "$0"|$1`">$3;rpub 'Jr ner Svt bs Obet.'"|$1|`$4 $2|$1`

[Mahmood Ali]

Greetings,

> Is that the intended behaviour or should the save method of MappedOneToManyBase
> be more like the one of Owned, except that it calls unowned foreach {_.save} ?

This issue has tripped me up before too. I suspect that OneToMany
field is intended to have a built-in delete behavior and should always
be mixed with a delete/unowned policy. Though, Mapper seems to
missing some sensible policies.

My solution was to introduce a Nullify mix-in, similar to
Owned/Cascade that sets the unowned foreign key to defaultValue (as
appropriate) upon delete_! and save calls.

> But even that may lead to inconsistencies if I remove a child from object A,
> add it as a child to object B, and then save A but discard the changes to B.
> (This might be the case for the current implementation of Owned, too).

I suspect that the intended behavior is context dependent, and
probably such action should be run within a transaction which would
revert object A changes as well.

- Mahmood

[Naftoli Gugenheim]

I thing you're right that it should be changed.

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.