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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
