In regards to mutability and thread-safety relationship lists are no
different from default Java lists (ArrayList), so I don't think we are
presenting an inconsistent picture. And I'd actually like server-side
objects to behave like ROP objects, not the other way around. (BTW,
CayenneDataObject is thread UNsafe on a more basic level - the map
that stores all values is not synchronized).
Adding immutable wrappers will also make CDO even heavier. In this
regard, here is another can of worms: to reconcile ROP and server-side
Cayenne and to make DO's lighter, some kind of POJO is the way to go
(which also solves DO thread-safety issue). This of course involves
class enhancement, etc.
Andrus
On Nov 12, 2009, at 12:09 AM, Aristedes Maniatis wrote:
> 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 : Thu Nov 12 2009 - 03:51:56 EST