You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Johannes <jo...@posteo.de> on 2015/12/05 16:19:41 UTC
setter for toMany in generated classes
Dear list,
I want to bring back my idea from February into discussion. It was about
introducing a setToManyTarget Method in the CayenneDataObject, but it
was not finished (mail archive:
http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
40objectstyle.org%3E )
My last action was, implementing Andrus advice to retrieve old
DataObjects, which can be deleted manually:
// sync...
List<? extends DataObject> removed =
o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
true);
// delete ... or not
// o.getObjectContext().deleteObjects(removed);
This was implemented immediatly by myself with following commit, but I
forgot to mention it on the list:
It was implemented in
https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
Best Regards.
Johannes
Re: Syncing DataContexts
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, the app reacting to an occasional inconsistency is probably a better approach then trying to synchronize many things at once.
Andrus
> On Dec 28, 2015, at 6:25 PM, Matt Watson <ma...@swarmbox.com> wrote:
>
> I just read about Optimistic Locking. Maybe that a strategy to use for a scenario like this.
>
> Matt
>> On Dec 24, 2015, at 12:45 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> Perhaps a change in Cayenne is due. E.g. if a cached snapshot is not the one object was committed against, we still need to dispatch the event as "invalidate" or something.
>>
>> Andrus
>>
>>> On Dec 18, 2015, at 3:00 AM, Matt Watson <ma...@swarmbox.com> wrote:
>>>
>>> Thanks Andrus,
>>>
>>> I was playing with this some more today, and it is calling ObjectStore.snapshotsChanged. When everything is working correctly, I can see the proper objects in “modifiedDiffs”, however when the object I expect to be in the modifiedDiff is not there, I can confirm that it was previously tossed out because of the “snapshot version changed, don’t know what to do”. I'm going to spend more time trying to figure out why this is occurring, but I’m pretty sure its coming from a “Select" of that object (resolving a ToOneFault).
>>>
>>> Since these “snapshot issues” are likely the culprit, does anyone have suggestions for how to avoid these? Is there a bad pattern I’m using within my code, that I should look for and replace?
>>>
>>> Thanks,
>>> Matt
>>>
>>>
>>>
>>>> On Dec 16, 2015, at 10:09 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>>>
>>>> Hi Matt,
>>>>
>>>>> On Dec 15, 2015, at 11:37 PM, Matt Watson <ma...@swarmbox.com> wrote:
>>>>> It is my understanding that if more than one ObjectContext has the same DataObject, when changes to that object are committed, the other context that has that same object will automatically be updated with the changes. But this does not seem to be happening for me.
>>>>
>>>> Within the same VM, yes, unless you turn it off explicitly. Try running in debugger with a breakpoint in ObjectStore.snapshotsChanged(..) method and see if it is called.
>>>>
>>>>> The specific scenario, is that I have two different people receiving product to the same PurchaseOrderLine. If they both bring in that PurchaseOrderLine before anything has been received, the “receivedQuantity” on that POL starts out at 0 (ZERO). When person A scans a box, the POL.receivedQuantity increments to 1, and then increments to 2 when he scans another. Then if person B scans a box, their POL still thinks the “receivedQuantity” is ZERO and it increments it to 1. So what I have in the database is a POL with receivedQuantity 1, but there are actually InventoryTransactions showing that it should be at 3.
>>>>
>>>> So I presume you commit after every scan? Again, this would mean the events should be propagated and merged into objects.
>>>>
>>>>> Not sure if this is related but we often see in the log during a commit -> "snapshot version changed, don't know what to do…”
>>>>
>>>> This can be related ... if this happens, IIRC Cayenne does not generate a snapshot event.
>>>>
>>>>> I read the Cayenne docs here (https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>) that it does not recommend using synchronization for a large number of users (peer Contexts), however I tested this with only 2 and still experience the issue. And now that I have just reread that documentation, I may have misunderstood that the object is automatically updated, and that instead the Context is notified of the changes via an event, but if I am not listening that event (& handling), then that could be why the other Context does not have the updated information on that object.
>>>>
>>>> In addition to poor performance characteristics, snapshot syncing is prone to various race conditions (e.g. an object property may get refreshed via an event, but then immediately overwritten from the UI), so its use is rather limited. I'd personally turn it off and use some other approach, e.g. optimistic locking in combination with query cache (query cache which was discussed a few days ago here [1].
>>>>
>>>> Andrus
>>>>
>>>> [1] http://stackoverflow.com/questions/34244260/cayenne-cache-does-query-cache-replace-object-cache
>>>>
>>>>
>>>
>>
>
Re: Syncing DataContexts
Posted by Matt Watson <ma...@swarmbox.com>.
I just read about Optimistic Locking. Maybe that a strategy to use for a scenario like this.
Matt
> On Dec 24, 2015, at 12:45 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Perhaps a change in Cayenne is due. E.g. if a cached snapshot is not the one object was committed against, we still need to dispatch the event as "invalidate" or something.
>
> Andrus
>
>> On Dec 18, 2015, at 3:00 AM, Matt Watson <ma...@swarmbox.com> wrote:
>>
>> Thanks Andrus,
>>
>> I was playing with this some more today, and it is calling ObjectStore.snapshotsChanged. When everything is working correctly, I can see the proper objects in “modifiedDiffs”, however when the object I expect to be in the modifiedDiff is not there, I can confirm that it was previously tossed out because of the “snapshot version changed, don’t know what to do”. I'm going to spend more time trying to figure out why this is occurring, but I’m pretty sure its coming from a “Select" of that object (resolving a ToOneFault).
>>
>> Since these “snapshot issues” are likely the culprit, does anyone have suggestions for how to avoid these? Is there a bad pattern I’m using within my code, that I should look for and replace?
>>
>> Thanks,
>> Matt
>>
>>
>>
>>> On Dec 16, 2015, at 10:09 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>>
>>> Hi Matt,
>>>
>>>> On Dec 15, 2015, at 11:37 PM, Matt Watson <ma...@swarmbox.com> wrote:
>>>> It is my understanding that if more than one ObjectContext has the same DataObject, when changes to that object are committed, the other context that has that same object will automatically be updated with the changes. But this does not seem to be happening for me.
>>>
>>> Within the same VM, yes, unless you turn it off explicitly. Try running in debugger with a breakpoint in ObjectStore.snapshotsChanged(..) method and see if it is called.
>>>
>>>> The specific scenario, is that I have two different people receiving product to the same PurchaseOrderLine. If they both bring in that PurchaseOrderLine before anything has been received, the “receivedQuantity” on that POL starts out at 0 (ZERO). When person A scans a box, the POL.receivedQuantity increments to 1, and then increments to 2 when he scans another. Then if person B scans a box, their POL still thinks the “receivedQuantity” is ZERO and it increments it to 1. So what I have in the database is a POL with receivedQuantity 1, but there are actually InventoryTransactions showing that it should be at 3.
>>>
>>> So I presume you commit after every scan? Again, this would mean the events should be propagated and merged into objects.
>>>
>>>> Not sure if this is related but we often see in the log during a commit -> "snapshot version changed, don't know what to do…”
>>>
>>> This can be related ... if this happens, IIRC Cayenne does not generate a snapshot event.
>>>
>>>> I read the Cayenne docs here (https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>) that it does not recommend using synchronization for a large number of users (peer Contexts), however I tested this with only 2 and still experience the issue. And now that I have just reread that documentation, I may have misunderstood that the object is automatically updated, and that instead the Context is notified of the changes via an event, but if I am not listening that event (& handling), then that could be why the other Context does not have the updated information on that object.
>>>
>>> In addition to poor performance characteristics, snapshot syncing is prone to various race conditions (e.g. an object property may get refreshed via an event, but then immediately overwritten from the UI), so its use is rather limited. I'd personally turn it off and use some other approach, e.g. optimistic locking in combination with query cache (query cache which was discussed a few days ago here [1].
>>>
>>> Andrus
>>>
>>> [1] http://stackoverflow.com/questions/34244260/cayenne-cache-does-query-cache-replace-object-cache
>>>
>>>
>>
>
Re: Syncing DataContexts
Posted by Andrus Adamchik <an...@objectstyle.org>.
Perhaps a change in Cayenne is due. E.g. if a cached snapshot is not the one object was committed against, we still need to dispatch the event as "invalidate" or something.
Andrus
> On Dec 18, 2015, at 3:00 AM, Matt Watson <ma...@swarmbox.com> wrote:
>
> Thanks Andrus,
>
> I was playing with this some more today, and it is calling ObjectStore.snapshotsChanged. When everything is working correctly, I can see the proper objects in “modifiedDiffs”, however when the object I expect to be in the modifiedDiff is not there, I can confirm that it was previously tossed out because of the “snapshot version changed, don’t know what to do”. I'm going to spend more time trying to figure out why this is occurring, but I’m pretty sure its coming from a “Select" of that object (resolving a ToOneFault).
>
> Since these “snapshot issues” are likely the culprit, does anyone have suggestions for how to avoid these? Is there a bad pattern I’m using within my code, that I should look for and replace?
>
> Thanks,
> Matt
>
>
>
>> On Dec 16, 2015, at 10:09 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>>
>> Hi Matt,
>>
>>> On Dec 15, 2015, at 11:37 PM, Matt Watson <ma...@swarmbox.com> wrote:
>>> It is my understanding that if more than one ObjectContext has the same DataObject, when changes to that object are committed, the other context that has that same object will automatically be updated with the changes. But this does not seem to be happening for me.
>>
>> Within the same VM, yes, unless you turn it off explicitly. Try running in debugger with a breakpoint in ObjectStore.snapshotsChanged(..) method and see if it is called.
>>
>>> The specific scenario, is that I have two different people receiving product to the same PurchaseOrderLine. If they both bring in that PurchaseOrderLine before anything has been received, the “receivedQuantity” on that POL starts out at 0 (ZERO). When person A scans a box, the POL.receivedQuantity increments to 1, and then increments to 2 when he scans another. Then if person B scans a box, their POL still thinks the “receivedQuantity” is ZERO and it increments it to 1. So what I have in the database is a POL with receivedQuantity 1, but there are actually InventoryTransactions showing that it should be at 3.
>>
>> So I presume you commit after every scan? Again, this would mean the events should be propagated and merged into objects.
>>
>>> Not sure if this is related but we often see in the log during a commit -> "snapshot version changed, don't know what to do…”
>>
>> This can be related ... if this happens, IIRC Cayenne does not generate a snapshot event.
>>
>>> I read the Cayenne docs here (https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>) that it does not recommend using synchronization for a large number of users (peer Contexts), however I tested this with only 2 and still experience the issue. And now that I have just reread that documentation, I may have misunderstood that the object is automatically updated, and that instead the Context is notified of the changes via an event, but if I am not listening that event (& handling), then that could be why the other Context does not have the updated information on that object.
>>
>> In addition to poor performance characteristics, snapshot syncing is prone to various race conditions (e.g. an object property may get refreshed via an event, but then immediately overwritten from the UI), so its use is rather limited. I'd personally turn it off and use some other approach, e.g. optimistic locking in combination with query cache (query cache which was discussed a few days ago here [1].
>>
>> Andrus
>>
>> [1] http://stackoverflow.com/questions/34244260/cayenne-cache-does-query-cache-replace-object-cache
>>
>>
>
Re: Syncing DataContexts
Posted by Matt Watson <ma...@swarmbox.com>.
Thanks Andrus,
I was playing with this some more today, and it is calling ObjectStore.snapshotsChanged. When everything is working correctly, I can see the proper objects in “modifiedDiffs”, however when the object I expect to be in the modifiedDiff is not there, I can confirm that it was previously tossed out because of the “snapshot version changed, don’t know what to do”. I'm going to spend more time trying to figure out why this is occurring, but I’m pretty sure its coming from a “Select" of that object (resolving a ToOneFault).
Since these “snapshot issues” are likely the culprit, does anyone have suggestions for how to avoid these? Is there a bad pattern I’m using within my code, that I should look for and replace?
Thanks,
Matt
> On Dec 16, 2015, at 10:09 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Hi Matt,
>
>> On Dec 15, 2015, at 11:37 PM, Matt Watson <ma...@swarmbox.com> wrote:
>> It is my understanding that if more than one ObjectContext has the same DataObject, when changes to that object are committed, the other context that has that same object will automatically be updated with the changes. But this does not seem to be happening for me.
>
> Within the same VM, yes, unless you turn it off explicitly. Try running in debugger with a breakpoint in ObjectStore.snapshotsChanged(..) method and see if it is called.
>
>> The specific scenario, is that I have two different people receiving product to the same PurchaseOrderLine. If they both bring in that PurchaseOrderLine before anything has been received, the “receivedQuantity” on that POL starts out at 0 (ZERO). When person A scans a box, the POL.receivedQuantity increments to 1, and then increments to 2 when he scans another. Then if person B scans a box, their POL still thinks the “receivedQuantity” is ZERO and it increments it to 1. So what I have in the database is a POL with receivedQuantity 1, but there are actually InventoryTransactions showing that it should be at 3.
>
> So I presume you commit after every scan? Again, this would mean the events should be propagated and merged into objects.
>
>> Not sure if this is related but we often see in the log during a commit -> "snapshot version changed, don't know what to do…”
>
> This can be related ... if this happens, IIRC Cayenne does not generate a snapshot event.
>
>> I read the Cayenne docs here (https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>) that it does not recommend using synchronization for a large number of users (peer Contexts), however I tested this with only 2 and still experience the issue. And now that I have just reread that documentation, I may have misunderstood that the object is automatically updated, and that instead the Context is notified of the changes via an event, but if I am not listening that event (& handling), then that could be why the other Context does not have the updated information on that object.
>
> In addition to poor performance characteristics, snapshot syncing is prone to various race conditions (e.g. an object property may get refreshed via an event, but then immediately overwritten from the UI), so its use is rather limited. I'd personally turn it off and use some other approach, e.g. optimistic locking in combination with query cache (query cache which was discussed a few days ago here [1].
>
> Andrus
>
> [1] http://stackoverflow.com/questions/34244260/cayenne-cache-does-query-cache-replace-object-cache
>
>
Re: Syncing DataContexts
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Matt,
> On Dec 15, 2015, at 11:37 PM, Matt Watson <ma...@swarmbox.com> wrote:
> It is my understanding that if more than one ObjectContext has the same DataObject, when changes to that object are committed, the other context that has that same object will automatically be updated with the changes. But this does not seem to be happening for me.
Within the same VM, yes, unless you turn it off explicitly. Try running in debugger with a breakpoint in ObjectStore.snapshotsChanged(..) method and see if it is called.
> The specific scenario, is that I have two different people receiving product to the same PurchaseOrderLine. If they both bring in that PurchaseOrderLine before anything has been received, the “receivedQuantity” on that POL starts out at 0 (ZERO). When person A scans a box, the POL.receivedQuantity increments to 1, and then increments to 2 when he scans another. Then if person B scans a box, their POL still thinks the “receivedQuantity” is ZERO and it increments it to 1. So what I have in the database is a POL with receivedQuantity 1, but there are actually InventoryTransactions showing that it should be at 3.
So I presume you commit after every scan? Again, this would mean the events should be propagated and merged into objects.
> Not sure if this is related but we often see in the log during a commit -> "snapshot version changed, don't know what to do…”
This can be related ... if this happens, IIRC Cayenne does not generate a snapshot event.
> I read the Cayenne docs here (https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>) that it does not recommend using synchronization for a large number of users (peer Contexts), however I tested this with only 2 and still experience the issue. And now that I have just reread that documentation, I may have misunderstood that the object is automatically updated, and that instead the Context is notified of the changes via an event, but if I am not listening that event (& handling), then that could be why the other Context does not have the updated information on that object.
In addition to poor performance characteristics, snapshot syncing is prone to various race conditions (e.g. an object property may get refreshed via an event, but then immediately overwritten from the UI), so its use is rather limited. I'd personally turn it off and use some other approach, e.g. optimistic locking in combination with query cache (query cache which was discussed a few days ago here [1].
Andrus
[1] http://stackoverflow.com/questions/34244260/cayenne-cache-does-query-cache-replace-object-cache
Syncing DataContexts
Posted by Matt Watson <ma...@swarmbox.com>.
I’m not sure if we are doing something wrong, but we are experiencing odd behavior related to DataObjects that exist in multiple contexts.
In our application we use a single ServerRuntime, and each user that connects (via handheld scanner) gets their own context ( serverRuntime.newContext() )
It is my understanding that if more than one ObjectContext has the same DataObject, when changes to that object are committed, the other context that has that same object will automatically be updated with the changes. But this does not seem to be happening for me.
The specific scenario, is that I have two different people receiving product to the same PurchaseOrderLine. If they both bring in that PurchaseOrderLine before anything has been received, the “receivedQuantity” on that POL starts out at 0 (ZERO). When person A scans a box, the POL.receivedQuantity increments to 1, and then increments to 2 when he scans another. Then if person B scans a box, their POL still thinks the “receivedQuantity” is ZERO and it increments it to 1. So what I have in the database is a POL with receivedQuantity 1, but there are actually InventoryTransactions showing that it should be at 3.
Not sure if this is related but we often see in the log during a commit -> "snapshot version changed, don't know what to do…”
I doubt this is normal behavior and figure its indicating we are doing something wrong, but I’m not sure what.
Has anyone else experienced anything like this or have any suggestions for me.
I read the Cayenne docs here (https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts <https://cayenne.apache.org/docs/4.0/cayenne-guide/performance-tuning.html#turning-off-synchronization-of-objectcontexts>) that it does not recommend using synchronization for a large number of users (peer Contexts), however I tested this with only 2 and still experience the issue. And now that I have just reread that documentation, I may have misunderstood that the object is automatically updated, and that instead the Context is notified of the changes via an event, but if I am not listening that event (& handling), then that could be why the other Context does not have the updated information on that object.
Thanks,
Matt
Re: setter for toMany in generated classes
Posted by Johannes <jo...@posteo.de>.
It is https://github.com/apache/cayenne/pull/80
Am 22.12.2015 um 08:25 schrieb Andrus Adamchik:
>> Is this ready for a pull request?
>> https://github.com/jotpe/cayenne/commits/master
>
> Go for it.
>
>
>> On Dec 21, 2015, at 10:57 PM, Johannes <jo...@posteo.de> wrote:
>>
>> Thank you.
>>
>> I commited 4 test classes. The main part is in
>> org.apache.cayenne.CayenneDataObjectSetToManyListTest
>>
>> The other 3 classes, just make sure there is no problem (exception) with
>> another relation collection type.
>>
>> 'mvn test' runs cayenne-server without any error.
>> There are no new checkstyle warnings.
>>
>> Is this ready for a pull request?
>> https://github.com/jotpe/cayenne/commits/master
>>
>> Johannes
>>
>>
>>
>> Am 15.12.2015 um 07:58 schrieb Andrus Adamchik:
>>> We have a few such test entities:
>>>
>>> 1. Map: cayenne-map-to-many.xml (CayenneProjects.MAP_TO_MANY_PROJECT)
>>> 2. Set: cayenne-relationships-set-to-many.xml (CayenneProjects.RELATIONSHIPS_SET_TO_MANY_PROJECT)
>>>
>>> Since those are in different projects, you will need to create separate test classes for them.
>>>
>>> Andrus
>>>
>>>
>>>> On Dec 13, 2015, at 2:21 PM, Johannes <jo...@posteo.de> wrote:
>>>>
>>>> Currently I am writing the unit tests for the new method.
>>>>
>>>> Most test cases are done with following class introduction (copied from
>>>> another test class in that package):
>>>>
>>>> @UseServerRuntime(CayenneProjects.TESTMAP_PROJECT)
>>>> public class CayenneDataObjectSetToMany extends ServerCase {
>>>>
>>>> @Inject
>>>> private ServerRuntime runtime;
>>>>
>>>> @Inject
>>>> private ObjectContext context;
>>>>
>>>> @Inject
>>>> private DBHelper dbHelper;
>>>>
>>>> protected TableHelper tArtist;
>>>> protected TableHelper tPainting;
>>>> .....
>>>>
>>>> Calling artist.getPaintingArray() returns an ArrayList, which was fine
>>>> yet. Now I need to configure my test environment to return different
>>>> collection types (collection, list, map and set).
>>>>
>>>> What is the best way to achieve that?
>>>>
>>>> Best regards
>>>> Johannes
>>>>
>>>> Am 07.12.2015 um 07:33 schrieb Andrus Adamchik:
>>>>> Thanks for the new version. Looks good to me. Let's maybe write some unit tests and create a new pull request.
>>>>>
>>>>> Andrus
>>>>>
>>>>>> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>>>>>>
>>>>>> Sure, here is a tidy commit:
>>>>>> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>>>>>>
>>>>>> Didn't know how to manipulate commits afterwards. I closed the pull
>>>>>> request and made my clean commit on a fresh reforked master version.
>>>>>>
>>>>>> Best Regards. Johannes
>>>>>>
>>>>>> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>>>>>>> Great. Do you want to tidy up the commits on your pull request.
>>>>>>>
>>>>>>> https://github.com/apache/cayenne/pull/61/commits
>>>>>>>
>>>>>>> Ari
>>>>>>>
>>>>>>> On 6/12/2015 2:19am, Johannes wrote:
>>>>>>>> Dear list,
>>>>>>>>
>>>>>>>> I want to bring back my idea from February into discussion. It was about
>>>>>>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>>>>>>> was not finished (mail archive:
>>>>>>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>>>>>>> 40objectstyle.org%3E )
>>>>>>>>
>>>>>>>>
>>>>>>>> My last action was, implementing Andrus advice to retrieve old
>>>>>>>> DataObjects, which can be deleted manually:
>>>>>>>>
>>>>>>>> // sync...
>>>>>>>> List<? extends DataObject> removed =
>>>>>>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>>>>>>> true);
>>>>>>>>
>>>>>>>> // delete ... or not
>>>>>>>> // o.getObjectContext().deleteObjects(removed);
>>>>>>>>
>>>>>>>>
>>>>>>>> This was implemented immediatly by myself with following commit, but I
>>>>>>>> forgot to mention it on the list:
>>>>>>>> It was implemented in
>>>>>>>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards.
>>>>>>>> Johannes
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
Re: setter for toMany in generated classes
Posted by Andrus Adamchik <an...@objectstyle.org>.
> Is this ready for a pull request?
> https://github.com/jotpe/cayenne/commits/master
Go for it.
> On Dec 21, 2015, at 10:57 PM, Johannes <jo...@posteo.de> wrote:
>
> Thank you.
>
> I commited 4 test classes. The main part is in
> org.apache.cayenne.CayenneDataObjectSetToManyListTest
>
> The other 3 classes, just make sure there is no problem (exception) with
> another relation collection type.
>
> 'mvn test' runs cayenne-server without any error.
> There are no new checkstyle warnings.
>
> Is this ready for a pull request?
> https://github.com/jotpe/cayenne/commits/master
>
> Johannes
>
>
>
> Am 15.12.2015 um 07:58 schrieb Andrus Adamchik:
>> We have a few such test entities:
>>
>> 1. Map: cayenne-map-to-many.xml (CayenneProjects.MAP_TO_MANY_PROJECT)
>> 2. Set: cayenne-relationships-set-to-many.xml (CayenneProjects.RELATIONSHIPS_SET_TO_MANY_PROJECT)
>>
>> Since those are in different projects, you will need to create separate test classes for them.
>>
>> Andrus
>>
>>
>>> On Dec 13, 2015, at 2:21 PM, Johannes <jo...@posteo.de> wrote:
>>>
>>> Currently I am writing the unit tests for the new method.
>>>
>>> Most test cases are done with following class introduction (copied from
>>> another test class in that package):
>>>
>>> @UseServerRuntime(CayenneProjects.TESTMAP_PROJECT)
>>> public class CayenneDataObjectSetToMany extends ServerCase {
>>>
>>> @Inject
>>> private ServerRuntime runtime;
>>>
>>> @Inject
>>> private ObjectContext context;
>>>
>>> @Inject
>>> private DBHelper dbHelper;
>>>
>>> protected TableHelper tArtist;
>>> protected TableHelper tPainting;
>>> .....
>>>
>>> Calling artist.getPaintingArray() returns an ArrayList, which was fine
>>> yet. Now I need to configure my test environment to return different
>>> collection types (collection, list, map and set).
>>>
>>> What is the best way to achieve that?
>>>
>>> Best regards
>>> Johannes
>>>
>>> Am 07.12.2015 um 07:33 schrieb Andrus Adamchik:
>>>> Thanks for the new version. Looks good to me. Let's maybe write some unit tests and create a new pull request.
>>>>
>>>> Andrus
>>>>
>>>>> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>>>>>
>>>>> Sure, here is a tidy commit:
>>>>> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>>>>>
>>>>> Didn't know how to manipulate commits afterwards. I closed the pull
>>>>> request and made my clean commit on a fresh reforked master version.
>>>>>
>>>>> Best Regards. Johannes
>>>>>
>>>>> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>>>>>> Great. Do you want to tidy up the commits on your pull request.
>>>>>>
>>>>>> https://github.com/apache/cayenne/pull/61/commits
>>>>>>
>>>>>> Ari
>>>>>>
>>>>>> On 6/12/2015 2:19am, Johannes wrote:
>>>>>>> Dear list,
>>>>>>>
>>>>>>> I want to bring back my idea from February into discussion. It was about
>>>>>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>>>>>> was not finished (mail archive:
>>>>>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>>>>>> 40objectstyle.org%3E )
>>>>>>>
>>>>>>>
>>>>>>> My last action was, implementing Andrus advice to retrieve old
>>>>>>> DataObjects, which can be deleted manually:
>>>>>>>
>>>>>>> // sync...
>>>>>>> List<? extends DataObject> removed =
>>>>>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>>>>>> true);
>>>>>>>
>>>>>>> // delete ... or not
>>>>>>> // o.getObjectContext().deleteObjects(removed);
>>>>>>>
>>>>>>>
>>>>>>> This was implemented immediatly by myself with following commit, but I
>>>>>>> forgot to mention it on the list:
>>>>>>> It was implemented in
>>>>>>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>>>>>
>>>>>>>
>>>>>>> Best Regards.
>>>>>>> Johannes
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
Re: setter for toMany in generated classes
Posted by Johannes <jo...@posteo.de>.
Thank you.
I commited 4 test classes. The main part is in
org.apache.cayenne.CayenneDataObjectSetToManyListTest
The other 3 classes, just make sure there is no problem (exception) with
another relation collection type.
'mvn test' runs cayenne-server without any error.
There are no new checkstyle warnings.
Is this ready for a pull request?
https://github.com/jotpe/cayenne/commits/master
Johannes
Am 15.12.2015 um 07:58 schrieb Andrus Adamchik:
> We have a few such test entities:
>
> 1. Map: cayenne-map-to-many.xml (CayenneProjects.MAP_TO_MANY_PROJECT)
> 2. Set: cayenne-relationships-set-to-many.xml (CayenneProjects.RELATIONSHIPS_SET_TO_MANY_PROJECT)
>
> Since those are in different projects, you will need to create separate test classes for them.
>
> Andrus
>
>
>> On Dec 13, 2015, at 2:21 PM, Johannes <jo...@posteo.de> wrote:
>>
>> Currently I am writing the unit tests for the new method.
>>
>> Most test cases are done with following class introduction (copied from
>> another test class in that package):
>>
>> @UseServerRuntime(CayenneProjects.TESTMAP_PROJECT)
>> public class CayenneDataObjectSetToMany extends ServerCase {
>>
>> @Inject
>> private ServerRuntime runtime;
>>
>> @Inject
>> private ObjectContext context;
>>
>> @Inject
>> private DBHelper dbHelper;
>>
>> protected TableHelper tArtist;
>> protected TableHelper tPainting;
>> .....
>>
>> Calling artist.getPaintingArray() returns an ArrayList, which was fine
>> yet. Now I need to configure my test environment to return different
>> collection types (collection, list, map and set).
>>
>> What is the best way to achieve that?
>>
>> Best regards
>> Johannes
>>
>> Am 07.12.2015 um 07:33 schrieb Andrus Adamchik:
>>> Thanks for the new version. Looks good to me. Let's maybe write some unit tests and create a new pull request.
>>>
>>> Andrus
>>>
>>>> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>>>>
>>>> Sure, here is a tidy commit:
>>>> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>>>>
>>>> Didn't know how to manipulate commits afterwards. I closed the pull
>>>> request and made my clean commit on a fresh reforked master version.
>>>>
>>>> Best Regards. Johannes
>>>>
>>>> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>>>>> Great. Do you want to tidy up the commits on your pull request.
>>>>>
>>>>> https://github.com/apache/cayenne/pull/61/commits
>>>>>
>>>>> Ari
>>>>>
>>>>> On 6/12/2015 2:19am, Johannes wrote:
>>>>>> Dear list,
>>>>>>
>>>>>> I want to bring back my idea from February into discussion. It was about
>>>>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>>>>> was not finished (mail archive:
>>>>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>>>>> 40objectstyle.org%3E )
>>>>>>
>>>>>>
>>>>>> My last action was, implementing Andrus advice to retrieve old
>>>>>> DataObjects, which can be deleted manually:
>>>>>>
>>>>>> // sync...
>>>>>> List<? extends DataObject> removed =
>>>>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>>>>> true);
>>>>>>
>>>>>> // delete ... or not
>>>>>> // o.getObjectContext().deleteObjects(removed);
>>>>>>
>>>>>>
>>>>>> This was implemented immediatly by myself with following commit, but I
>>>>>> forgot to mention it on the list:
>>>>>> It was implemented in
>>>>>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>>>>
>>>>>>
>>>>>> Best Regards.
>>>>>> Johannes
>>>>>>
>>>>>
>>>>
>>>>
>>
Re: setter for toMany in generated classes
Posted by Andrus Adamchik <an...@objectstyle.org>.
We have a few such test entities:
1. Map: cayenne-map-to-many.xml (CayenneProjects.MAP_TO_MANY_PROJECT)
2. Set: cayenne-relationships-set-to-many.xml (CayenneProjects.RELATIONSHIPS_SET_TO_MANY_PROJECT)
Since those are in different projects, you will need to create separate test classes for them.
Andrus
> On Dec 13, 2015, at 2:21 PM, Johannes <jo...@posteo.de> wrote:
>
> Currently I am writing the unit tests for the new method.
>
> Most test cases are done with following class introduction (copied from
> another test class in that package):
>
> @UseServerRuntime(CayenneProjects.TESTMAP_PROJECT)
> public class CayenneDataObjectSetToMany extends ServerCase {
>
> @Inject
> private ServerRuntime runtime;
>
> @Inject
> private ObjectContext context;
>
> @Inject
> private DBHelper dbHelper;
>
> protected TableHelper tArtist;
> protected TableHelper tPainting;
> .....
>
> Calling artist.getPaintingArray() returns an ArrayList, which was fine
> yet. Now I need to configure my test environment to return different
> collection types (collection, list, map and set).
>
> What is the best way to achieve that?
>
> Best regards
> Johannes
>
> Am 07.12.2015 um 07:33 schrieb Andrus Adamchik:
>> Thanks for the new version. Looks good to me. Let's maybe write some unit tests and create a new pull request.
>>
>> Andrus
>>
>>> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>>>
>>> Sure, here is a tidy commit:
>>> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>>>
>>> Didn't know how to manipulate commits afterwards. I closed the pull
>>> request and made my clean commit on a fresh reforked master version.
>>>
>>> Best Regards. Johannes
>>>
>>> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>>>> Great. Do you want to tidy up the commits on your pull request.
>>>>
>>>> https://github.com/apache/cayenne/pull/61/commits
>>>>
>>>> Ari
>>>>
>>>> On 6/12/2015 2:19am, Johannes wrote:
>>>>> Dear list,
>>>>>
>>>>> I want to bring back my idea from February into discussion. It was about
>>>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>>>> was not finished (mail archive:
>>>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>>>> 40objectstyle.org%3E )
>>>>>
>>>>>
>>>>> My last action was, implementing Andrus advice to retrieve old
>>>>> DataObjects, which can be deleted manually:
>>>>>
>>>>> // sync...
>>>>> List<? extends DataObject> removed =
>>>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>>>> true);
>>>>>
>>>>> // delete ... or not
>>>>> // o.getObjectContext().deleteObjects(removed);
>>>>>
>>>>>
>>>>> This was implemented immediatly by myself with following commit, but I
>>>>> forgot to mention it on the list:
>>>>> It was implemented in
>>>>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>>>
>>>>>
>>>>> Best Regards.
>>>>> Johannes
>>>>>
>>>>
>>>
>>>
>
Re: setter for toMany in generated classes
Posted by Johannes <jo...@posteo.de>.
Currently I am writing the unit tests for the new method.
Most test cases are done with following class introduction (copied from
another test class in that package):
@UseServerRuntime(CayenneProjects.TESTMAP_PROJECT)
public class CayenneDataObjectSetToMany extends ServerCase {
@Inject
private ServerRuntime runtime;
@Inject
private ObjectContext context;
@Inject
private DBHelper dbHelper;
protected TableHelper tArtist;
protected TableHelper tPainting;
.....
Calling artist.getPaintingArray() returns an ArrayList, which was fine
yet. Now I need to configure my test environment to return different
collection types (collection, list, map and set).
What is the best way to achieve that?
Best regards
Johannes
Am 07.12.2015 um 07:33 schrieb Andrus Adamchik:
> Thanks for the new version. Looks good to me. Let's maybe write some unit tests and create a new pull request.
>
> Andrus
>
>> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>>
>> Sure, here is a tidy commit:
>> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>>
>> Didn't know how to manipulate commits afterwards. I closed the pull
>> request and made my clean commit on a fresh reforked master version.
>>
>> Best Regards. Johannes
>>
>> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>>> Great. Do you want to tidy up the commits on your pull request.
>>>
>>> https://github.com/apache/cayenne/pull/61/commits
>>>
>>> Ari
>>>
>>> On 6/12/2015 2:19am, Johannes wrote:
>>>> Dear list,
>>>>
>>>> I want to bring back my idea from February into discussion. It was about
>>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>>> was not finished (mail archive:
>>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>>> 40objectstyle.org%3E )
>>>>
>>>>
>>>> My last action was, implementing Andrus advice to retrieve old
>>>> DataObjects, which can be deleted manually:
>>>>
>>>> // sync...
>>>> List<? extends DataObject> removed =
>>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>>> true);
>>>>
>>>> // delete ... or not
>>>> // o.getObjectContext().deleteObjects(removed);
>>>>
>>>>
>>>> This was implemented immediatly by myself with following commit, but I
>>>> forgot to mention it on the list:
>>>> It was implemented in
>>>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>>
>>>>
>>>> Best Regards.
>>>> Johannes
>>>>
>>>
>>
>>
Re: setter for toMany in generated classes
Posted by Johannes <jo...@posteo.de>.
Hello Michael,
yes, this was Andrus idea. I like it.
----------------
Perhaps one
other way to deal with deletions, is to return a collection of removed
objects from the method,
leaving it up to the caller to deal with them:
// sync...
List<? extends DataObject> removed =
o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
true);
// delete ... or not
// o.getObjectContext().deleteObjects(removed);
------------
Am 07.12.2015 um 16:49 schrieb Michael Gentry:
> Hi Johannes,
>
> Are you anticipating something like this if you want to actually delete
> objects instead of just unlink them?
>
> dataContext.deleteObjects(cayenneDataObject.setToManyTarget(...));
>
> Thanks,
>
> mrg
>
>
> On Mon, Dec 7, 2015 at 1:33 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> Thanks for the new version. Looks good to me. Let's maybe write some unit
>> tests and create a new pull request.
>>
>> Andrus
>>
>>> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>>>
>>> Sure, here is a tidy commit:
>>>
>> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>>>
>>> Didn't know how to manipulate commits afterwards. I closed the pull
>>> request and made my clean commit on a fresh reforked master version.
>>>
>>> Best Regards. Johannes
>>>
>>> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>>>> Great. Do you want to tidy up the commits on your pull request.
>>>>
>>>> https://github.com/apache/cayenne/pull/61/commits
>>>>
>>>> Ari
>>>>
>>>> On 6/12/2015 2:19am, Johannes wrote:
>>>>> Dear list,
>>>>>
>>>>> I want to bring back my idea from February into discussion. It was
>> about
>>>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>>>> was not finished (mail archive:
>>>>>
>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>>>> 40objectstyle.org%3E )
>>>>>
>>>>>
>>>>> My last action was, implementing Andrus advice to retrieve old
>>>>> DataObjects, which can be deleted manually:
>>>>>
>>>>> // sync...
>>>>> List<? extends DataObject> removed =
>>>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>>>> true);
>>>>>
>>>>> // delete ... or not
>>>>> // o.getObjectContext().deleteObjects(removed);
>>>>>
>>>>>
>>>>> This was implemented immediatly by myself with following commit, but I
>>>>> forgot to mention it on the list:
>>>>> It was implemented in
>>>>>
>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>>>
>>>>>
>>>>> Best Regards.
>>>>> Johannes
>>>>>
>>>>
>>>
>>>
>>
>>
>
Re: setter for toMany in generated classes
Posted by Michael Gentry <mg...@masslight.net>.
Hi Johannes,
Are you anticipating something like this if you want to actually delete
objects instead of just unlink them?
dataContext.deleteObjects(cayenneDataObject.setToManyTarget(...));
Thanks,
mrg
On Mon, Dec 7, 2015 at 1:33 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> Thanks for the new version. Looks good to me. Let's maybe write some unit
> tests and create a new pull request.
>
> Andrus
>
> > On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
> >
> > Sure, here is a tidy commit:
> >
> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
> >
> > Didn't know how to manipulate commits afterwards. I closed the pull
> > request and made my clean commit on a fresh reforked master version.
> >
> > Best Regards. Johannes
> >
> > Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
> >> Great. Do you want to tidy up the commits on your pull request.
> >>
> >> https://github.com/apache/cayenne/pull/61/commits
> >>
> >> Ari
> >>
> >> On 6/12/2015 2:19am, Johannes wrote:
> >>> Dear list,
> >>>
> >>> I want to bring back my idea from February into discussion. It was
> about
> >>> introducing a setToManyTarget Method in the CayenneDataObject, but it
> >>> was not finished (mail archive:
> >>>
> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
> >>> 40objectstyle.org%3E )
> >>>
> >>>
> >>> My last action was, implementing Andrus advice to retrieve old
> >>> DataObjects, which can be deleted manually:
> >>>
> >>> // sync...
> >>> List<? extends DataObject> removed =
> >>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
> >>> true);
> >>>
> >>> // delete ... or not
> >>> // o.getObjectContext().deleteObjects(removed);
> >>>
> >>>
> >>> This was implemented immediatly by myself with following commit, but I
> >>> forgot to mention it on the list:
> >>> It was implemented in
> >>>
> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
> >>>
> >>>
> >>> Best Regards.
> >>> Johannes
> >>>
> >>
> >
> >
>
>
Re: setter for toMany in generated classes
Posted by Andrus Adamchik <an...@objectstyle.org>.
Thanks for the new version. Looks good to me. Let's maybe write some unit tests and create a new pull request.
Andrus
> On Dec 7, 2015, at 1:07 AM, Johannes <jo...@posteo.de> wrote:
>
> Sure, here is a tidy commit:
> https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
>
> Didn't know how to manipulate commits afterwards. I closed the pull
> request and made my clean commit on a fresh reforked master version.
>
> Best Regards. Johannes
>
> Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
>> Great. Do you want to tidy up the commits on your pull request.
>>
>> https://github.com/apache/cayenne/pull/61/commits
>>
>> Ari
>>
>> On 6/12/2015 2:19am, Johannes wrote:
>>> Dear list,
>>>
>>> I want to bring back my idea from February into discussion. It was about
>>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>>> was not finished (mail archive:
>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>>> 40objectstyle.org%3E )
>>>
>>>
>>> My last action was, implementing Andrus advice to retrieve old
>>> DataObjects, which can be deleted manually:
>>>
>>> // sync...
>>> List<? extends DataObject> removed =
>>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>>> true);
>>>
>>> // delete ... or not
>>> // o.getObjectContext().deleteObjects(removed);
>>>
>>>
>>> This was implemented immediatly by myself with following commit, but I
>>> forgot to mention it on the list:
>>> It was implemented in
>>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>>
>>>
>>> Best Regards.
>>> Johannes
>>>
>>
>
>
Re: setter for toMany in generated classes
Posted by Johannes <jo...@posteo.de>.
Sure, here is a tidy commit:
https://github.com/apache/cayenne/commit/1358dad4e3ae2cf2735aa223b869e4b85f18508e
Didn't know how to manipulate commits afterwards. I closed the pull
request and made my clean commit on a fresh reforked master version.
Best Regards. Johannes
Am 06.12.2015 um 10:05 schrieb Aristedes Maniatis:
> Great. Do you want to tidy up the commits on your pull request.
>
> https://github.com/apache/cayenne/pull/61/commits
>
> Ari
>
> On 6/12/2015 2:19am, Johannes wrote:
>> Dear list,
>>
>> I want to bring back my idea from February into discussion. It was about
>> introducing a setToManyTarget Method in the CayenneDataObject, but it
>> was not finished (mail archive:
>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
>> 40objectstyle.org%3E )
>>
>>
>> My last action was, implementing Andrus advice to retrieve old
>> DataObjects, which can be deleted manually:
>>
>> // sync...
>> List<? extends DataObject> removed =
>> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
>> true);
>>
>> // delete ... or not
>> // o.getObjectContext().deleteObjects(removed);
>>
>>
>> This was implemented immediatly by myself with following commit, but I
>> forgot to mention it on the list:
>> It was implemented in
>> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>>
>>
>> Best Regards.
>> Johannes
>>
>
Re: setter for toMany in generated classes
Posted by Aristedes Maniatis <ar...@maniatis.org>.
Great. Do you want to tidy up the commits on your pull request.
https://github.com/apache/cayenne/pull/61/commits
Ari
On 6/12/2015 2:19am, Johannes wrote:
> Dear list,
>
> I want to bring back my idea from February into discussion. It was about
> introducing a setToManyTarget Method in the CayenneDataObject, but it
> was not finished (mail archive:
> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201501.mbox/%3C0DBA750D-A847-4CC1-8EAC-9DCFB5A0FECA%
> 40objectstyle.org%3E )
>
>
> My last action was, implementing Andrus advice to retrieve old
> DataObjects, which can be deleted manually:
>
> // sync...
> List<? extends DataObject> removed =
> o.setToManyTarget(Artist.PAINTINGS.getName(), newPaintings,
> true);
>
> // delete ... or not
> // o.getObjectContext().deleteObjects(removed);
>
>
> This was implemented immediatly by myself with following commit, but I
> forgot to mention it on the list:
> It was implemented in
> https://github.com/jotpe/cayenne/commit/b930886a9ab24fa8b82a7e8efeaf6d2437bd5d96
>
>
> Best Regards.
> Johannes
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A