Hi Jeremy,
The real issue is that you used “addObjectsToBothSidesOfRelationship()”
Had you added to only one side of the relationship… If you only set the to-one,
then the “to-many back relationship” would not have been tripped.
This is why NeXT gave you the option to choose. If you don’t need the “to-many”
updated at that moment then do not do “bothSides” - set only the to-one.
Now, that said, Chuck is absolutely right. If the toMany is that painful, it is
better not to expose it in the model. It is all to easy to trip it when you
don’t want and even if you do want it… it very well could blow out memory.
While it has been convenient for you to utilize the “toMany” relationship in
your programming, it is now a problem for you because your app is growing.
Chuck’s advice is best, remove it from being a visible property in your EOModel
and find another way to serve that data efficiently. You will probably want to
fetch parts of that relationship and not see ALL orders at once. It’s just too
much data for you now.
AARON ROSENZWEIG / Chat 'n Bike
e: aa...@chatnbike.com t: (301) 956-2319
On Jun 6, 2016, at 11:44 AM, Jérémy DE ROYER <jeremy.dero...@ingencys.net>
wrote:
> According to yours posts, it seems that for performance reasons, we have to
> think twice (or more) before adding a reverse to Many relationship.
>
> Before removing all the non-usefull to Many relationships and add the
> associated delete controls, I have one more question (sic) :
> - What’s the difference, in an EOModel, between a to Many relationship
> without Class Property and a to Many relationship with Class Property ?
> (or : Is it worth keeping them or is it better deleting all of them)
>
> Jérémy
>
>> Le 6 juin 2016 à 14:48, Samuel Pelletier <sam...@samkar.com> a écrit :
>>
>> Jérémy,
>>
>> You can keep a cache of the results inside your EO. As the EO is specific to
>> an EOEditingContext, it will be refreshed often if you use the pattern of
>> creating a new EOEditingContext per main WOComponent.
>>
>> BTW, the toMany is triggered by the fact we ask EOF to update the reverse
>> relationships. By using an EO in a toOne, we add this EO to the reverse
>> toMany, to add an object to an array, this array needs to exists.
>>
>> Samuel
>>
>>
>>> Le 5 juin 2016 à 18:49, Jérémy DE ROYER <jeremy.dero...@ingencys.net> a
>>> écrit :
>>>
>>> I tried this way last week but if it's faster when saving, it is much
>>> slower when reading because it fetches each time without caching...
>>>
>>> The reading performances are really good but I have to find a way to speed
>>> up when inserting new objects that "overuse" the database and slow down the
>>> other users
>>>
>>> Jeremy
>>>
>>> Le 6 juin 2016 à 00:33, Chuck Hill <ch...@gevityinc.com> a écrit :
>>>
>>>> That is what I meant by fetching. You need to re-implement those methods.
>>>> Change it to do an fetch on Customer where modeTransport == this
>>>>
>>>> You can still use it to fetch a ModeTransport based on “listOrder contains
>>>> order”.
>>>> Chuck
>>>>
>>>>
>>>> From: Jérémy DE ROYER <jeremy.dero...@ingencys.net>
>>>> Date: Sunday, June 5, 2016 at 3:26 PM
>>>> To: Chuck Hill <ch...@gevityinc.com>
>>>> Cc: WebObjects-Dev <webobjects-dev@lists.apple.com>
>>>> Subject: Re: How to avoid expensive fetches in database when setting
>>>> to-one-relationship
>>>>
>>>> What do you mean with « you can still use it for fetching » ?
>>>>
>>>> I removed the class property for the Customer to Order (but keeped the «
>>>> listOrder » relationship)
>>>>
>>>> When I set the customer to the order, it runs fast.
>>>>
>>>> But when I retrieve the orders using the method below :
>>>>
>>>> public NSArray<Customer> listOrder() {
>>>> return (NSArray<Customer>)storedValueForKey("listOrder");
>>>> }
>>>>
>>>> I get an error :
>>>>
>>>> <com.webobjects.foundation.NSKeyValueCoding$UnknownKeyException message
>>>> ‘<Customer 0x72c7423b> valueForKey(): lookup of unknown key: 'listOrder'.
>>>> This class does not have an instance variable of the name listOrder or
>>>> _listOrder, nor a method of the name listOrder _listOrder, getListOrder,
>>>> or _getListOrder' object ‘{...}' key 'listOrder'>
>>>> at
>>>> com.webobjects.foundation.NSKeyValueCoding$DefaultImplementation.handleQueryWithUnboundKey(NSKeyValueCoding.java:1377)
>>>> at
>>>> com.webobjects.eocontrol.EOCustomObject.handleQueryWithUnboundKey(EOCustomObject.java:1545)
>>>> at
>>>> com.webobjects.foundation.NSKeyValueCoding$Utility.handleQueryWithUnboundKey(NSKeyValueCoding.java:494)
>>>> at
>>>> com.webobjects.foundation.NSKeyValueCoding$_KeyBinding.valueInObject(NSKeyValueCoding.java:894)
>>>> at
>>>> com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
>>>> at Customer.listeOrder(_Customer.java:890)
>>>>
>>>> Where am I wrong ?
>>>>
>>>> Jérémy
>>>>
>>>> Le 5 juin 2016 à 22:04, Chuck Hill <ch...@gevityinc.com> a écrit :
>>>>
>>>> Remove the “class property” setting for the ModeTransport to Order. You
>>>> can still use it for fetching.
>>>>
>>>> Chuck
>>>>
>>>>
>>>> From: <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on
>>>> behalf of Jérémy DE ROYER <jeremy.dero...@ingencys.net>
>>>> Date: Sunday, June 5, 2016 at 12:55 PM
>>>> To: WebObjects-Dev <webobjects-dev@lists.apple.com>
>>>> Subject: How to avoid expensive fetches in database when setting
>>>> to-one-relationship
>>>>
>>>> Dear all,
>>>>
>>>> In our app, we have a one to many relationship between order and mode
>>>> transport
>>>>
>>>> For each order, we set the mode transport using the method below :
>>>>
>>>>
>>>> public void setModeTransportRelationship(ModeTransport value) {
>>>> if (_CommandeClient.LOG.isDebugEnabled()) {
>>>> _CommandeClient.LOG.debug("updating modeTransport from " +
>>>> modeTransport() + " to " + value);
>>>> }
>>>> if (value == null) {
>>>> ModeTransport oldValue = modeTransport();
>>>> if (oldValue != null) {
>>>> removeObjectFromBothSidesOfRelationshipWithKey(oldValue,
>>>> "modeTransport");
>>>> }
>>>> } else {
>>>> addObjectToBothSidesOfRelationshipWithKey(value, "modeTransport");
>>>> }
>>>> }
>>>>
>>>>
>>>> Then, an objectWillChange() is fired for the mode transport… but the (not
>>>> wished) consequence is that every to many relationships from the mode
>>>> transport are fetched (even if we don’t call the associated method for the
>>>> mode transport). However, the objects associated with the to one
>>>> relationships are not fetched.
>>>>
>>>> We observed the same behavior for the customer object when using the
>>>> setCustomerRelationship method of the ordre. The (bigger) problem is that
>>>> the customer object has dozen of to many relationships... fetched for
>>>> nothing…
>>>>
>>>> At the beginning we had few orders but now, we have to wait from 10 to 30
>>>> seconds until de saveChange is ended and that’s really not effective. More
>>>> than 90 % of this time is spent for fetching the to many relationship
>>>> whereas we just had to save the order values...
>>>>
>>>> Any idea how to deal with theses not-wished-fetches ?
>>>>
>>>> Jérémy
>>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
>>>
>>> This email sent to sam...@samkar.com
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
>
> This email sent to aa...@chatnbike.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
