Bin Sun wrote:
Hi, David!
SCOCollection.add() may be implemented with lazy
feature, and you're right at this point. However,
convinience is also a concern for me. Since I had
noted the bi-directional attribute for a collection in
the metadata, I should be allowed to modify one side
of them and let the impl. do the last. As I said.
Sure, and it would be a handy feature [1]. But since under the current
spec and its pending proposal, you don't get FULLY-managed
relationships, there is a span of time - between when you update one
side and when you finally commit - when the other side of the
relationship is NOT updated. Does this partway solution meet any
programming need of yours?
To illustrate, using our Invoice and Line classes from before, under the
current and proposed specs, you are being offered the following behaviour:
static {
PersistenceManager pm = Util.aquirePM();
pm.currentTransaction().begin();
Invoice inv = Util.lookupInvoice(pm, "1234"); // only has 0 lines
when picked up.
Line line = new Line();
line.setInvoice(inv); // we'll just update 1 side, because section
15.3 lets us take a shortcut
assert (inv.getLines().contains(line)); // assertion fails
pm.currentTransaction().commit(); // RetainValues or
DetachAllOnCommit are true.
assert (inv.getLines().contains(line)); // assertion succeeds
}
Notice how the same assertion yields different results before and after
commit. Is that really the behaviour you want of your
PersistenceManager? I know you *really* want fully-managed
relationships, but since you can't have them, are you truly happy with
the above situation[2]?
sincerely,
David.
[1] Although it only saves you one simple line of code.
[2] As I hope I've made clear by now, I'm not happy with it, and I
regard this behaviour as obnoxious. Nobody has so far presented any
argument at all as to why I should be happy with it.
