Re: Dealing with relationships and inheritance
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