Re: restricting qualifiers and join entities
Re: restricting qualifiers and join entities
- Subject: Re: restricting qualifiers and join entities
- From: Chuck Hill <email@hidden>
- Date: Wed, 4 Jun 2008 15:12:59 -0700
On Jun 4, 2008, at 3:02 PM, Lachlan Deck wrote:
On 05/06/2008, at 4:25 AM, Chuck Hill wrote:
On Jun 3, 2008, at 9:44 PM, Lachlan Deck wrote:
On 04/06/2008, at 1:19 PM, Lachlan Deck wrote:
On 04/06/2008, at 12:58 PM, Chuck Hill wrote:
On Jun 3, 2008, at 7:26 PM, Lachlan Deck wrote:
Say I have entities Foo and Bar (both of which have an
attribute isDeleted) and a join FooBar and I create restricting
qualifiers for Foo and Bar of (isDeleted IS NULL OR isDeleted =
0).
Foo.fooBars() still fetches all fooBars even if pointing to a
Bar that cannot be instantiated due to the restricting qualifier.
So my question is: should EOF filter such joins automatically
(i.e., should I file a bug) or is it just up to me to auto-
apply these restricting qualifiers?
I would expect that to work for fetches. In the past I have had
a relationship to a subclass in a single table inheritance
hierarchy, and I recall that only the correct instances were
fetched.
Yeah, and I just checked again and I already have code that
automatically creates a restricting qualifier for joins by
migrating the restricting qualifiers from the related entities.
So I end up with:
9837 INFO [main] (er.extensions.ERXNSLogLog4jBridge, appendln,
38) -
willLoadEntity added restricting qualifier to:FooBar of
((foo.isDeleted <> (java.lang.Boolean)'true') and (bar.isDeleted
<> (java.lang.Boolean)'true'))
But if you're right, and EOF already uses this in its qualifier
then I probably don't need to be doing that.
I was trying really hard to not ask why you were doing that. ;-)
Well I wasn't sure what was meant to happen if just doing a fetch on
the non-flattened join entity itself (as opposed to following a
relationship).
Yeah, in that case you would need this.
I don't think you should need to do this if EOF is working correctly.
ok
I take that back. :-)
Have you checked the SQL and verified that they restricting
qualifier is not getting generated?
Will have to check again. Thanks.
See logs below. The FooBar restricting qualifier is not being
applied properly it seems.
Any ideas Pierre?
<<<
35238 DEBUG [WorkerThread15] (er.extensions.ERXNSLogLog4jBridge,
appendln, 44) -
evaluateExpression: <com.webobjects.jdbcadaptor.MySQLPlugIn
$MySQLExpression: "SELECT blah blah FROM FooBar t0, Taggable T2,
Foo T1 WHERE ((T2.isDeleted <> ? AND T2.isDeleted <> ?)
It seems quite wrong that it is doing this check twice on T2 and
not at all on T1.
Well there is no isDeleted in T1 (this is VI .. T2 is the super-
entity). Notice that Bar, which is also a sub-entity of T2 btw, is
not even in the select. i.e., there's no T3.
Head... hurts... must... not... read... message....
At this point I am starting to wonder if restricting qualifiers are
compatible with VI, or at least your particular use of it.
Is it possible that your entity loading code has a typo? Or is this
the bug you think is in EOF?
I suspect the latter but I'll have to test if this is happening
twice, once from the restricting qualifier set on the join by my
code at app launch, once automatically by EOF (from what you're
saying).
er, not any more. I think that EOF is just not able to make the SQL
you need. I am not even really sure what that SQL is, but not curious
enough to try and figure it out. I will leave it as an exercise for
the reader.
AND t0.fooId = ?) AND T1.id = T2.id AND t0.fooId = T1.id ORDER BY
whatever" withBindings: 1:true(isDeleted), 2:true(isDeleted),
3:145310(fooId)>
35242 DEBUG [WorkerThread15] (er.extensions.ERXNSLogLog4jBridge,
appendln, 44) -
1 row(s) processed
>>>
So by this stage it's selected/faulted the join entity instance. Now
it proceeds to attempt to follow the relationship to Bar...
<<<
35287 DEBUG [WorkerThread15] (er.extensions.ERXNSLogLog4jBridge,
appendln, 44) -
evaluateExpression: <com.webobjects.jdbcadaptor.MySQLPlugIn
$MySQLExpression: "SELECT T1.x, T0.y, blah etc FROM Bar t0,
Taggable T1 WHERE ((T1.entityType = ? AND T1.isDeleted <> ?) AND
t0.id = ?) AND t0.id = T1.id ORDER BY whatever" withBindings:
1:"Bar"(entityType), 2:true(isDeleted), 3:4818(id)>
35292 DEBUG [WorkerThread15] (er.extensions.ERXNSLogLog4jBridge,
appendln, 44) -
0 row(s) processed
>>>
35325 ERROR [WorkerThread15] (willow.view.DynamicDirectAction,
directActionName, 248) -
Failed to obtain key baz available for object:{values = {... lots
of NSKeyValueCoding$Null values as not yet faulted...}; this =
"<willow.model.Bar 12f9924 _EOIntegralKeyGlobalID[Bar
(java.lang.Long)4818]>"; }
What part of that select is not matching? Are you getting bitten
by nulls?
This last part is, I assume, a failed lazy relationship fault from
the join to Bar.
Right, because it picked up a PK for a row excluded by the restricting
qualifier.
Chuck and still not sold on VI ;-)
er.extensions.ERXDatabaseContextDelegate
$ObjectNotAvailableException: No willow.model.Bar found with
globalID: <Bar: [id: '4818'] >
at
er
.extensions
.ERXDatabaseContextDelegate
.databaseContextFailedToFetchObject
(ERXDatabaseContextDelegate.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com
.webobjects
.foundation.NSSelector._safeInvokeMethod(NSSelector.java:120)
at
com.webobjects.foundation._NSDelegate._perform(_NSDelegate.java:225)
at com.webobjects.foundation._NSDelegate.perform(_NSDelegate.java:
170)
at
com
.webobjects
.eoaccess.EODatabaseContext._fireFault(EODatabaseContext.java:4384)
at
com
.webobjects
.eoaccess
.EOAccessFaultHandler
.completeInitializationOfObject(EOAccessFaultHandler.java:85)
at
com
.webobjects.eocontrol.EOCustomObject.willRead(EOCustomObject.java:
1189)
at com.webobjects.eocontrol._EOMutableKnownKeyDictionary
$Initializer
$
_GenericRecordBinding
.valueInObject(_EOMutableKnownKeyDictionary.java:519)
at
com
.webobjects
.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:
1736)
at com.ish.willow.eoaccess.model._Taggable.angelId(_Taggable.java:
104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.webobjects.foundation.NSKeyValueCoding$ValueAccessor
$1.methodValue(NSKeyValueCoding.java:684)
at com.webobjects.foundation.NSKeyValueCoding
$_MethodBinding.valueInObject(NSKeyValueCoding.java:1160)
at
com
.webobjects
.eocontrol.EOCustomObject.valueForKey(EOCustomObject.java:1559)
<...>
with regards,
--
Lachlan Deck
--
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