multiple levels of inheritance shouldn't really matter with respect to batch faulting for single table inheritance (which i assume he's using based on the restricting qualifier references) ... what DOES matter is if you refer to abstract entities, which requires tripping faults to know what type of java object to return to you. maybe i'm just not thinking of a particular bug, but i wouldn't think this should be a big problem.
also, if you wanted to REMOVE the big "OR" restricting qualifier off of single-table inheritance fetch, you can do it by overriding EOEntity._singleTableRestrictingQualifier(), but you can ONLY do this if the particular entity has no parent entity and if you KNOW (i.e., probably flag the entity in the model) that you have an onto (in the mathematical sense) map to your table with your restricting qualifiers. ms On Mar 23, 2011, at 11:05 AM, Jon Nolan wrote: > Understood Ken. Good point and I know you're right about performance > trade-offs. I've not given up just yet but I'll take your words to heart. > > On 3/22/11 9:29 PM, Ken Anderson wrote: >> Jon, >> >> My point was that SQL optimizations are much easier to implement (I use >> Oracle too) without an inheritance hierarchy, since EOF is less involved in >> building queries to handle the structure. I actually have a situation today >> where I regret using 2 levels of inheritance because I cannot tune the >> queries as needed, causing a significant degradation of performance. This >> is especially true with 2 level hierarchies and batch faulting. EOF is just >> unable to resolve the super-entities correctly. When I tested changing it >> to a one level hierarchy, performance increased a thousand fold. >> >> In any case, best of luck! >> >> Ken >> >> On Mar 22, 2011, at 11:04 PM, Jon Nolan wrote: >> >>> Hi Ken, >>> >>> The inheritance is absolutely necessary and works a treat. My example EO >>> tree is just that, an example for the sake of simplicity. The real model >>> supports social network content types and is fairly esoteric (the example >>> is easy to understand and is a valid representation). While quite >>> complicated our model supports our needs almost perfectly. The differences >>> in behavior between types can be substantial. >>> >>> The behavior of the objects and the structure of the model isn't the >>> problem. The problem is very much localized to data retrieval speed and is >>> more an Oracle issue than a Web Objects one. I'm trying to optimize it in >>> various ways - some on the WO side and others on the DB side. I'm not >>> considering throwing away the substantial benefits of our model design. >>> >>> The specific behavior I'm looking for is influencing Oracle's optimizer to >>> NOT do full table scans when retrieving these objects. Getting rid of big >>> OR qualifiers, controlling the order of restricting v. non-restricting >>> qualifiers, utilizing hints, using views, etc. All in play. >>> >>> Thanks, >>> Jon >>> >>> >>> >>> On 3/22/11 8:18 PM, Ken Anderson wrote: >>>> Not to put a crimp in your model, but is inheritance really necessary >>>> here? What actual behavior is different? >>>> >>>> One level inheritance is hard to optimize - two levels, doubly so (at >>>> least!). If you could share more about what kind of behavior you're >>>> looking for from these objects it might be helpful to everyone on the list. >>>> >>>> Ken >>>> >>>> On Mar 22, 2011, at 7:31 PM, Jon Nolan wrote: >>>> >>>>> I have a fairly involved EO inheritance tree that works beautifully in >>>>> every way but one. Here's a quick example illustrating the structure I'm >>>>> using: >>>>> >>>>> Human >>>>> North American >>>>> American >>>>> Canadian >>>>> Mexican >>>>> European >>>>> German >>>>> Italian >>>>> Spaniard >>>>> Asian >>>>> Korean >>>>> Laotian >>>>> >>>>> etc. You get the idea. >>>>> >>>>> So if I utilize European.fetchEuropeans(...) a qualifier is generated >>>>> along the lines of HUMAN_TYPE = German or HUMAN_TYPE = Italian or >>>>> HUMAN_TYPE = Spaniard. This would be fine except for the Oracle >>>>> optimizer deciding not to use the HUMAN_TYPE_IDX index. I've tried using >>>>> hints but (a) it's difficult to get right for a query generated by a >>>>> ERXBatchingDisplayGroup and (b) the JDBC adaptor disconnects me when I >>>>> try. >>>>> >>>>> There is another qualifier clause which happens to make it so that, in >>>>> the European example, all the returned humans will indeed be German, >>>>> Italian or Spaniard. Is there any way to simply discard the OR'd >>>>> HUMAN_TYPE qualifier? Any other suggestions? Do I have something wrong >>>>> in my model in the first place? >>>>> >>>>> Thanks, >>>>> Jon >>>>> _______________________________________________ >>>>> 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: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com >>>>> >>>>> This email sent tokenli...@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: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com > > This email sent to msch...@pobox.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: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
