Thank’s.

I will keep my model with the to-Many relationship, remove the class property…
…and (re)ceate all the methods to fetch objects, check when deleting et 
optimize the access to such a lists.

I'll start with the customers class and keep you informed,

Jérémy

Le 6 juin 2016 à 19:21, Ken Anderson 
<kenli...@anderhome.com<mailto:kenli...@anderhome.com>> a écrit :

One other reason - non class property relationships help EOF resolve abstract 
entity relationships when prefetching.  Without the non-class property back 
pointing relationships, the prefetched sub-entities don’t get connected 
properly.

On Jun 6, 2016, at 12:58 PM, Chuck Hill 
<ch...@gevityinc.com<mailto:ch...@gevityinc.com>> wrote:

Relationships that are a class property are fetched and maintained by EOF.  
Relationships that are not a class property are just names that you can use in 
a fetch specification – it tells EOF how to navigate the joins but EOF will not 
fetch or manage them.

Chuck


From: Jérémy DE ROYER 
<jeremy.dero...@ingencys.net<mailto:jeremy.dero...@ingencys.net>>
Date: Monday, June 6, 2016 at 8:44 AM
To: Samuel Pelletier <sam...@samkar.com<mailto:sam...@samkar.com>>
Cc: Chuck Hill <ch...@gevityinc.com<mailto:ch...@gevityinc.com>>, Philippe 
Rabier <prab...@icloud.com<mailto:prab...@icloud.com>>, 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

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<mailto: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<mailto: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<mailto: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<mailto:sam...@samkar.com>


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      
(Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com

This email sent to kenli...@anderhome.com<mailto:kenli...@anderhome.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