cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [suggestion] unmodifiable toMany lists
Date Thu, 12 Nov 2009 08:51:19 GMT
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
>


Mime
View raw message