On 12/11/09 2:44 AM, Kevin Menard wrote:
> 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?
>
> It gets a little worse when you add your own custom collection methods
> (i.e., not DB backed) and it's not clear what type you're working
> with.
>
> Don't get me wrong, it's wholly a human problem. But, false
> expectations can lead to tedious debugging sessions and adoptions of
> seemingly tenuous programming habits.
Yes, that's very nicely explained. And in addition, the collections which are returned are not thread safe. So that's another issue to have to remember. As you say, this issue is purely about developers making mistakes in their code and not remembering that a list which was passed through 15 function calls actually has a special purpose that rewrites the database.
Even that special purpose is not completely consistent. Although it looks like a List, Cayenne treats it like a Set: reordering the list doesn't cause a database operation.
On 12/11/09 3:20 AM, Andrus Adamchik wrote:
> This is why I am in favor of a single strategy that can be clearly
> explained in the docs. IMO the only problem today is a mismatch between
> server-side and ROP behavior (if I am not mistaken ROP allows
> collection.add/remove, while server-side requires you to use generated
> methods addTo/removeFrom). Otherwise I think we are consistent.
The proposal is actually to make that consistent: that is, require the user to use generated addTo/removeFrom methods in both server and client. We can do that by making the default templates generate immutable collections.
> Wrapping collections into immutable wrappers is not something I'd like
> Cayenne to do. Let the users do it if they want to, either in the code,
> or via a very simple customized cgen template.
Since the read-only approach is somewhat less prone to foot-shooting, should we make that the default template (and maybe have a simple commented out block in the template for the alternative approach)?
Ari Maniatis
----------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Wed Nov 11 2009 - 17:10:11 EST