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 
> <mailto: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 
>> <mailto:jeremy.dero...@ingencys.net>>
>> Date: Sunday, June 5, 2016 at 3:26 PM
>> To: Chuck Hill <ch...@gevityinc.com <mailto:ch...@gevityinc.com>>
>> Cc: WebObjects-Dev <webobjects-dev@lists.apple.com 
>> <mailto: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 
>> <mailto: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 
>> <mailto:webobjects-dev-bounces+chill=gevityinc....@lists.apple.com>> on 
>> behalf of Jérémy DE ROYER <jeremy.dero...@ingencys.net 
>> <mailto:jeremy.dero...@ingencys.net>>
>> Date: Sunday, June 5, 2016 at 12:55 PM
>> To: WebObjects-Dev <webobjects-dev@lists.apple.com 
>> <mailto: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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to