Kevin Menard wrote:
> On Wed, Nov 11, 2009 at 1:13 AM, Dirk Olmes <dir..anthippe.ping.de> wrote:
>
>>> Right. They are...but this (I believe) is too easily exposed to user
>>> code. e.g.,
>>> for (Bar relation : foo.allBars()) {
>>> if (some condition) {
>>> foo.removeFromAllBars(relation); // will throw exception
>>> }
>>> }
>> Err, why is this? Because you're modifying the collection you're
>> iterating over? I'd rather fix the iterator then.
>
> The "problem" exists outside the context of an iterator, too. What
> would you expect the semantics to be of the following?
>
> foo.allBars.remove(for.allBars.get(0));
>
> Should it just modify the in-memory list or should it represent the
> backing DB and represent a DELETE operation?
You're absolutely right. I was thinking only in terms of ObjEntity based
relationship collections but in any non-trivial setup I'd expect mapped
classes to have other methods returning collections (e.g. ones that
filter on relationships). It would be hard for users to know when the
underlying DB is modified upon modification of the collection and when not.
So I guess returning unmodifiable collections and providing add/remove
custom methods from the generator templates is the better way to go.
-dirk
This archive was generated by hypermail 2.0.0 : Thu Nov 26 2009 - 21:10:49 EST