You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Alexander Lamb <al...@mac.com> on 2007/05/24 09:54:46 UTC
Behavior of "remove(object)" on ToManyList
Hello list,
I am fetching a "List" of objects (a too many relationship).
Then in a loop, I am removing some objects:
List<RegistryCenter> rcs = getRegistry().getRegistryCenters();
List centers = getSelectedCountry().getCenters();
for(RegistryCenter rc:rcs)
{
centers.remove(rc.getCenter());
}
Now, this doesn't always work. Actually, it fails if "centers" is a fault (I checked in the Cayenne code).
If I simply do a "size()" of "contains" on the list before my loop for example. My list will fire and my loop will function correctly, removing objects when present in the list.
So there is a workaround, but I was wondering why the "remove(object)" in ToManyList.java behaved differently than for example "remove(index)" which will correctly fire the fault.
In other words, "remove(object)" is the only function which does not systématically fire the fault.
Why?
Thanks,
Alex
Re: Behavior of "remove(object)" on ToManyList
Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually I see no problem with the list being modifiable, (dis)
connecting a relationship on remove/add. This fits into the ORM
model, as long as there is an understanding that a relationship list
is connected to a persistence engine, the same way individual objects
are.
Andrus
On May 30, 2007, at 6:20 AM, Kevin Menard wrote:
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Thursday, May 24, 2007 5:52 AM
>> To: user@cayenne.apache.org
>> Subject: Re: Behavior of "remove(object)" on ToManyList
>>
>> Hi Alex,
>>
>> Well, actually one of Cayenne responsibilities is maintaining
>> consistent object graph. To-many lists are a part of that
>> object graph. So if you want to remove an object from the
>> list for presentation reasons, but keep the relationship
>> intact, the only right way is to clone the list and remove
>> items from the clone. I.e.:
>>
>> List centers = new ArrayList(getSelectedCountry().getCenters());
>
> Perhaps it would make sense if the relationships return unmodifiable
> Lists then? It seems to me like it could clear up this whole class of
> problems.
>
> --
> Kevin
>
RE: Behavior of "remove(object)" on ToManyList
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Wednesday, May 30, 2007 8:15 AM
> To: user@cayenne.apache.org
> Subject: Re: Behavior of "remove(object)" on ToManyList
>
> ... and create its own set of problems. The data in memory is
> a working copy of what you expect the database to look like
> after you commit the transaction. And a very natural way of
> changing the data model is to simply change the collection
> that represents the relationship.
>
> If you made the collection read-only, then the only way to
> change the contents would be to make a working copy of the
> read-only collection, change it, and then replace the
> collection field in the domain object. So you're just trading
> off one inconvenience for another.
Fair enough. I guess I just never thought to manipulate the list
directly and initially expected it to work the same way that Alexander
had. I wonder if others new to the framework do as well.
--
Kevin
Re: Behavior of "remove(object)" on ToManyList
Posted by Craig L Russell <Cr...@Sun.COM>.
On May 29, 2007, at 8:20 PM, Kevin Menard wrote:
>> -----Original Message-----
>> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
>> Sent: Thursday, May 24, 2007 5:52 AM
>> To: user@cayenne.apache.org
>> Subject: Re: Behavior of "remove(object)" on ToManyList
>>
>> Hi Alex,
>>
>> Well, actually one of Cayenne responsibilities is maintaining
>> consistent object graph. To-many lists are a part of that
>> object graph. So if you want to remove an object from the
>> list for presentation reasons, but keep the relationship
>> intact, the only right way is to clone the list and remove
>> items from the clone. I.e.:
>>
>> List centers = new ArrayList(getSelectedCountry().getCenters());
>
> Perhaps it would make sense if the relationships return unmodifiable
> Lists then? It seems to me like it could clear up this whole class of
> problems.
... and create its own set of problems. The data in memory is a
working copy of what you expect the database to look like after you
commit the transaction. And a very natural way of changing the data
model is to simply change the collection that represents the
relationship.
If you made the collection read-only, then the only way to change the
contents would be to make a working copy of the read-only collection,
change it, and then replace the collection field in the domain
object. So you're just trading off one inconvenience for another.
Both JDO and JPA return read-write collections and allow you to
modify the contents with the intent of updating the database with the
changes...
Craig
>
> --
> Kevin
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Behavior of "remove(object)" on ToManyList
Posted by Kevin Menard <km...@servprise.com>.
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Thursday, May 24, 2007 5:52 AM
> To: user@cayenne.apache.org
> Subject: Re: Behavior of "remove(object)" on ToManyList
>
> Hi Alex,
>
> Well, actually one of Cayenne responsibilities is maintaining
> consistent object graph. To-many lists are a part of that
> object graph. So if you want to remove an object from the
> list for presentation reasons, but keep the relationship
> intact, the only right way is to clone the list and remove
> items from the clone. I.e.:
>
> List centers = new ArrayList(getSelectedCountry().getCenters());
Perhaps it would make sense if the relationships return unmodifiable
Lists then? It seems to me like it could clear up this whole class of
problems.
--
Kevin
RE: Cayenne version 1 vs. version 2
Posted by Kevin Menard <km...@servprise.com>.
1.2.x and 2.0.x are designed to be the same thing, just with different
packages. So, the change should be fairly straightforward. The other
major difference is the license. 1.2.x uses the old ObjectStyle license
while 2.0.x used the Apache license. The two licenses were largely
compatible anyway, but it may something for you to consider as well.
--
Kevin
> -----Original Message-----
> From: Fredrik Liden [mailto:fliden@translate.com]
> Sent: Friday, May 25, 2007 3:06 PM
> To: user@cayenne.apache.org
> Subject: Cayenne version 1 vs. version 2
>
> Hi,
>
> I had created a project using Cayenne version 1.2 a while back.
> Is it correct that the only change between 1.2.3 and 2.0.3 is
> still just the package naming? Is the documentation pages
> identical between the two versions? And the modeler is the
> same as well?
>
> Thanks!
>
> Fredrik
>
Re: Cayenne version 1 vs. version 2
Posted by Bryan Lewis <br...@maine.rr.com>.
I switched from Cayenne 1.2 to 2.0 last December and had no trouble at
all. I did a global replace of the package names in my source and xml
config files and it worked fine.
Fredrik Liden wrote:
> Hi,
>
> I had created a project using Cayenne version 1.2 a while back.
> Is it correct that the only change between 1.2.3 and 2.0.3 is still just
> the package naming? Is the documentation pages identical between the two
> versions? And the modeler is the same as well?
>
> Thanks!
>
> Fredrik
>
>
Cayenne version 1 vs. version 2
Posted by Fredrik Liden <fl...@translate.com>.
Hi,
I had created a project using Cayenne version 1.2 a while back.
Is it correct that the only change between 1.2.3 and 2.0.3 is still just
the package naming? Is the documentation pages identical between the two
versions? And the modeler is the same as well?
Thanks!
Fredrik
Re: Behavior of "remove(object)" on ToManyList
Posted by Alexander Lamb <al...@mac.com>.
Thanks a lot. It is indeed the correct way to handle the problem.
Alex
On Thursday, May 24, 2007, at 11:52AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>Hi Alex,
>
>Well, actually one of Cayenne responsibilities is maintaining
>consistent object graph. To-many lists are a part of that object
>graph. So if you want to remove an object from the list for
>presentation reasons, but keep the relationship intact, the only
>right way is to clone the list and remove items from the clone. I.e.:
>
>List centers = new ArrayList(getSelectedCountry().getCenters());
>
>Andrus
>
>
>On May 24, 2007, at 12:36 PM, Alexander Lamb wrote:
>
>> Thanks Andrus, however, I am not doing relationship management in
>> that case.
>> Actually, I do NOT want to remove the center from the selected
>> country.
>>
>> What I am doing is taking the centers and removing some items to
>> present to the user the centers which are not already present in
>> another relationship.
>>
>> In other words: "remove from the centers of the country the ones
>> which are already used for a registry". Then present the list to
>> the user so he can select a center he may want to add for a
>> registry (or let him create a new center).
>>
>> So it is more like if I made a temporary copy of a list of objects
>> to work with.
>>
>> And, yes, for consistency it would seem better to first fire a list
>> fault before. But there was maybe some historical reason not to do
>> it (I looked in the code and there is some testing of the status of
>> the list and object that I didn't really understand).
>>
>> On Thursday, May 24, 2007, at 11:20AM, "Andrus Adamchik"
>> <an...@objectstyle.org> wrote:
>>> I suggest using "getSelectedCountry().removeFromCenters(..)" for
>>> consistent behavior. As for the remove, maybe we should fire a list
>>> fault for consistency, but this hasn't been a big deal as
>>> relationship management is better done via special methods.
>>>
>>> Andrus
>>>
>>>
>>> On May 24, 2007, at 10:54 AM, Alexander Lamb wrote:
>>>> Hello list,
>>>>
>>>> I am fetching a "List" of objects (a too many relationship).
>>>>
>>>> Then in a loop, I am removing some objects:
>>>>
>>>> List<RegistryCenter> rcs = getRegistry().getRegistryCenters();
>>>> List centers = getSelectedCountry().getCenters();
>>>> for(RegistryCenter rc:rcs)
>>>> {
>>>> centers.remove(rc.getCenter());
>>>> }
>>>>
>>>>
>>>> Now, this doesn't always work. Actually, it fails if "centers" is a
>>>> fault (I checked in the Cayenne code).
>>>>
>>>> If I simply do a "size()" of "contains" on the list before my loop
>>>> for example. My list will fire and my loop will function correctly,
>>>> removing objects when present in the list.
>>>>
>>>> So there is a workaround, but I was wondering why the "remove
>>>> (object)" in ToManyList.java behaved differently than for example
>>>> "remove(index)" which will correctly fire the fault.
>>>>
>>>> In other words, "remove(object)" is the only function which does
>>>> not systématically fire the fault.
>>>>
>>>> Why?
>>>>
>>>> Thanks,
>>>>
>>>> Alex
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Mapping to Mysql TEXT type
Posted by Andrus Adamchik <an...@objectstyle.org>.
On May 29, 2007, at 8:10 PM, Fredrik Liden wrote:
> If I want to use the Mysql TEXT datatype, how should I go about
> specifying that in the modeler? Should I use "Other" and then manually
> change it to TEXT in the database? Or should I use "Varchar" and
> set the
> maximum string length to be something more in line with real TEXT
> length?
>
> Thanks!
>
> Fredrik
Cayenne modeler DB types are the types from JDBC spec. So technically
TEXT corresponds to CLOB. In practice I think both CLOB and VARCHAR
should work.
Hope this helps.
Andrus
Mapping to Mysql TEXT type
Posted by Fredrik Liden <fl...@translate.com>.
If I want to use the Mysql TEXT datatype, how should I go about
specifying that in the modeler? Should I use "Other" and then manually
change it to TEXT in the database? Or should I use "Varchar" and set the
maximum string length to be something more in line with real TEXT
length?
Thanks!
Fredrik
Re: Behavior of "remove(object)" on ToManyList
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Alex,
Well, actually one of Cayenne responsibilities is maintaining
consistent object graph. To-many lists are a part of that object
graph. So if you want to remove an object from the list for
presentation reasons, but keep the relationship intact, the only
right way is to clone the list and remove items from the clone. I.e.:
List centers = new ArrayList(getSelectedCountry().getCenters());
Andrus
On May 24, 2007, at 12:36 PM, Alexander Lamb wrote:
> Thanks Andrus, however, I am not doing relationship management in
> that case.
> Actually, I do NOT want to remove the center from the selected
> country.
>
> What I am doing is taking the centers and removing some items to
> present to the user the centers which are not already present in
> another relationship.
>
> In other words: "remove from the centers of the country the ones
> which are already used for a registry". Then present the list to
> the user so he can select a center he may want to add for a
> registry (or let him create a new center).
>
> So it is more like if I made a temporary copy of a list of objects
> to work with.
>
> And, yes, for consistency it would seem better to first fire a list
> fault before. But there was maybe some historical reason not to do
> it (I looked in the code and there is some testing of the status of
> the list and object that I didn't really understand).
>
> On Thursday, May 24, 2007, at 11:20AM, "Andrus Adamchik"
> <an...@objectstyle.org> wrote:
>> I suggest using "getSelectedCountry().removeFromCenters(..)" for
>> consistent behavior. As for the remove, maybe we should fire a list
>> fault for consistency, but this hasn't been a big deal as
>> relationship management is better done via special methods.
>>
>> Andrus
>>
>>
>> On May 24, 2007, at 10:54 AM, Alexander Lamb wrote:
>>> Hello list,
>>>
>>> I am fetching a "List" of objects (a too many relationship).
>>>
>>> Then in a loop, I am removing some objects:
>>>
>>> List<RegistryCenter> rcs = getRegistry().getRegistryCenters();
>>> List centers = getSelectedCountry().getCenters();
>>> for(RegistryCenter rc:rcs)
>>> {
>>> centers.remove(rc.getCenter());
>>> }
>>>
>>>
>>> Now, this doesn't always work. Actually, it fails if "centers" is a
>>> fault (I checked in the Cayenne code).
>>>
>>> If I simply do a "size()" of "contains" on the list before my loop
>>> for example. My list will fire and my loop will function correctly,
>>> removing objects when present in the list.
>>>
>>> So there is a workaround, but I was wondering why the "remove
>>> (object)" in ToManyList.java behaved differently than for example
>>> "remove(index)" which will correctly fire the fault.
>>>
>>> In other words, "remove(object)" is the only function which does
>>> not systématically fire the fault.
>>>
>>> Why?
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>>
>>
>>
>>
>
Re: Behavior of "remove(object)" on ToManyList
Posted by Alexander Lamb <al...@mac.com>.
Thanks Andrus, however, I am not doing relationship management in that case.
Actually, I do NOT want to remove the center from the selected country.
What I am doing is taking the centers and removing some items to present to the user the centers which are not already present in another relationship.
In other words: "remove from the centers of the country the ones which are already used for a registry". Then present the list to the user so he can select a center he may want to add for a registry (or let him create a new center).
So it is more like if I made a temporary copy of a list of objects to work with.
And, yes, for consistency it would seem better to first fire a list fault before. But there was maybe some historical reason not to do it (I looked in the code and there is some testing of the status of the list and object that I didn't really understand).
On Thursday, May 24, 2007, at 11:20AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>I suggest using "getSelectedCountry().removeFromCenters(..)" for
>consistent behavior. As for the remove, maybe we should fire a list
>fault for consistency, but this hasn't been a big deal as
>relationship management is better done via special methods.
>
>Andrus
>
>
>On May 24, 2007, at 10:54 AM, Alexander Lamb wrote:
>> Hello list,
>>
>> I am fetching a "List" of objects (a too many relationship).
>>
>> Then in a loop, I am removing some objects:
>>
>> List<RegistryCenter> rcs = getRegistry().getRegistryCenters();
>> List centers = getSelectedCountry().getCenters();
>> for(RegistryCenter rc:rcs)
>> {
>> centers.remove(rc.getCenter());
>> }
>>
>>
>> Now, this doesn't always work. Actually, it fails if "centers" is a
>> fault (I checked in the Cayenne code).
>>
>> If I simply do a "size()" of "contains" on the list before my loop
>> for example. My list will fire and my loop will function correctly,
>> removing objects when present in the list.
>>
>> So there is a workaround, but I was wondering why the "remove
>> (object)" in ToManyList.java behaved differently than for example
>> "remove(index)" which will correctly fire the fault.
>>
>> In other words, "remove(object)" is the only function which does
>> not systématically fire the fault.
>>
>> Why?
>>
>> Thanks,
>>
>> Alex
>>
>>
>
>
>
Re: Behavior of "remove(object)" on ToManyList
Posted by Andrus Adamchik <an...@objectstyle.org>.
I suggest using "getSelectedCountry().removeFromCenters(..)" for
consistent behavior. As for the remove, maybe we should fire a list
fault for consistency, but this hasn't been a big deal as
relationship management is better done via special methods.
Andrus
On May 24, 2007, at 10:54 AM, Alexander Lamb wrote:
> Hello list,
>
> I am fetching a "List" of objects (a too many relationship).
>
> Then in a loop, I am removing some objects:
>
> List<RegistryCenter> rcs = getRegistry().getRegistryCenters();
> List centers = getSelectedCountry().getCenters();
> for(RegistryCenter rc:rcs)
> {
> centers.remove(rc.getCenter());
> }
>
>
> Now, this doesn't always work. Actually, it fails if "centers" is a
> fault (I checked in the Cayenne code).
>
> If I simply do a "size()" of "contains" on the list before my loop
> for example. My list will fire and my loop will function correctly,
> removing objects when present in the list.
>
> So there is a workaround, but I was wondering why the "remove
> (object)" in ToManyList.java behaved differently than for example
> "remove(index)" which will correctly fire the fault.
>
> In other words, "remove(object)" is the only function which does
> not systématically fire the fault.
>
> Why?
>
> Thanks,
>
> Alex
>
>