cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@maniatis.org>
Subject Re: [suggestion] unmodifiable toMany lists
Date Wed, 11 Nov 2009 22:09:34 GMT
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

Mime
View raw message