• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Dealing with relationships and inheritance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with relationships and inheritance


  • Subject: Re: Dealing with relationships and inheritance
  • From: Chuck Hill <email@hidden>
  • Date: Fri, 8 Feb 2008 08:57:49 -0800

I was fairly sure that I have seen this in other situations, but it might just have been using the EOUtilities methods which don't set isDeep.

Charles, are your table names identical in the model? What code is triggering the multiple selects on one table?

Chuck


On Feb 7, 2008, at 3:22 PM, Mike Schrag wrote:

So it appears (if I'm reading this code properly) that EOF merges restricting qualifiers for single table inheritance. In EOSQLExpression, if the fetch spec .isDeep() and if the entity._isSingleTableEntity(), then it will merge the restricting qualifiers together into a big EOOrQualifier (via EOEntity._singleTableRestrictingQualifier). So condition 1:

fetchspec.isDeep:
Note that EOUtilities does __NOT__ set isDeep on any of its fetch methods, which is why I use my eogenerated fetch methods that DO always set isDeep = true. I think I might consider this a bug. I got burned by this back in 2005 (there's a thread from 2005 where Chuck and I discuss this problem -- isDeep = false also means that cache in memory is bypassed), and I've used isDeep eogenerated methods ever since. I set this on EVERYTHING. I'm not sure what the downside of this is, but I've done it for over 2 years now and never noticed any problems, and lots of benefits.


entity._isSingleTableEntity:
Essentially this just comes down to whether or not EVERY SINGLE entity in the inheritance tree for your root entity are in the same table. It's possible that this is case sensitive -- it is only calling .equals(..) but maybe external name is lowercased/ uppercased somewhere earlier in the process. But check that EVERY entity defines the same table name.


Now Wonder has one more benefit here, which is that Wonder automagically turns OR's of the same keys into IN's, but that's relatively minor point here. Basically yours should be the same as below but with a bunch of OR's if you don't use Wonder.

ms

On Feb 7, 2008, at 4:31 PM, Mike Schrag wrote:

Any advice?

That it the way it is. I don't know how easy it would be to optimize these. EOF might expect there to be only a single entity per result set.
I was pretty sure I was not seeing this behavior, so I verified it in one of our apps:

to-many fault:
2008-02-07 16:14:27,535 DEBUG 17.9 MB/12.1 MB [WorkerThread1] extensions.ERXNSLogLog4jBridge - evaluateExpression: <com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression: "SELECT t0."cellTypeID", <snip> FROM "SheetCell" t0 WHERE (t0."cellTypeID" IN (1, 6, 4, 3, 2, 5) AND t0."rowID" = 1005629)">


top-level fetch:
2008-02-07 16:16:27,450 DEBUG 30.14 MB/3.26 MB [WorkerThread8] extensions.ERXNSLogLog4jBridge - evaluateExpression: <com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression: "SELECT t0."cellTypeID", <snip> FROM "SheetCell" t0 WHERE (t0."cellTypeID" IN (1, 6, 4, 3, 2, 5) AND t0."maxSlots" = 5)">


So it's not definitely not doing this. I tried with an abstract and non-abstract super-entity here, and got the same results.

I checked another app and tried a polymorphic to-one fault:
Feb 07 16:27:50 MDTask[60756] (ERXNSLogLog4jBridge.java:44) DEBUG NSLog - evaluateExpression: <com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression: "SELECT <snip> t0."RequestTypeNumber" <snipagain> FROM "Request" t0 WHERE (t0."RequestTypeNumber" IN (1, 2, 3) AND t0."RequestID" = 1006678)">


It's possible that Wonder fixes this, but I don't think I wrote that if it does ... I'll look through the code some. Can anyone not using Wonder verify this?

ms

--

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects






_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Dealing with relationships and inheritance (From: Charles Koppelman <email@hidden>)
 >Re: Dealing with relationships and inheritance (From: Chuck Hill <email@hidden>)
 >Re: Dealing with relationships and inheritance (From: Mike Schrag <email@hidden>)
 >Re: Dealing with relationships and inheritance (From: Mike Schrag <email@hidden>)

  • Prev by Date: Re: WOCheckBox to my instance
  • Next by Date: Re: NSNumberFormatter vs NumberFormat
  • Previous by thread: Re: Dealing with relationships and inheritance
  • Next by thread: Re: Dealing with relationships and inheritance
  • Index(es):
    • Date
    • Thread