Re: strange inheritance problem
Re: strange inheritance problem
- Subject: Re: strange inheritance problem
- From: Tim Worman <email@hidden>
- Date: Fri, 19 Jun 2009 10:21:25 -0700
On Jun 19, 2009, at 9:45 AM, David Avendasora wrote:
On Jun 19, 2009, at 12:20 PM, Tim Worman wrote:
On Jun 19, 2009, at 12:33 AM, David Avendasora wrote:
On Jun 19, 2009, at 2:00 AM, Tim Worman wrote:
On Jun 18, 2009, at 10:14 PM, Chuck Hill wrote:
Hi Tim,
On Jun 18, 2009, at 6:12 PM, Tim Worman wrote:
All:
I have some fetches that are not respecting the restricting
qualifiers in my model for a simple inheritance structure. I'm
using WO 5.4.3. This what I have:
Job >> Approver > Employee
I have subclassed Approver into PrimaryApprover and
DelegateApprover with the following restricting qualifiers. I
am using single table inheritance and applying a qualifier on
the attribute 'foo.'
PrimaryApprover - foo=1
DelegateApprover - foo>1
So, there also is:
Job.primaryapprovers()
Job.delegateapprovers()
Here's where I'm seeing trouble. I have a qualifier set to
fetch Job entities and it is defined like so:
EOKeyValueQualifier
("primaryapprovers.employee
",EOQualifier.QualifierOperatorEqual, someEmployee)
Whenever I perform a fetch against the Job entity with the
above qualifier it appears to fetch against the Approver
without any restricting qualifier (foo>1) being part of the
fetch.
I'm guessing this is just a typo, but if you're fetching a
primaryapprovers.employee, shouldn't that restricting qualifier be
foo=1 ?
Yeah, sorry that was a typo. It should have been foo=1.
When I log out the sql there is no mention in it of the foo
attribute.
Let's simplify. What does the SQL look like when you just follow
the approvers(), primaryapprovers() and delegateapprovers()
relationships? Does that get you the restricting qualifier in the
SQL?
Yes, absolutely. That is what is so maddening about it. If I use
aJob().primaryapprovers() in my code I will only get the primary
approvers for the job. The same goes for the delegateapprovers
relationship. The both return only the appropriate approvers - so
the restricting qualifier works there. The actual name of the
attribute I called 'foo' above is 'priority.'
To test I fetched a single Job and then asked for each of the
relationships. Here's what the sql looks like:
primaryapprovers()
SELECT t0.approver_id, t0.create_date, t0.emp_id, t0.job_id,
t0.level, t0.modify_date, t0.priority FROM APPROVER t0 WHERE
(t0.priority = ? AND t0.emp_id = ?)" withBindings: 1:1(priority),
2:"4028"(employeeId)>
correctly says priority=1
And the proper records are displayed.
delegateapprovers()
SELECT t0.approver_id, t0.create_date, t0.emp_id, t0.job_id,
t0.level, t0.modify_date, t0.priority FROM APPROVER t0 WHERE
(t0.priority > ? AND t0.emp_id = ?)" withBindings: 1:1(priority),
2:"4028"(employeeId)>
correctly says priority>1
And the proper records are displayed.
approvers()
When I use this both of the above fire and the proper records are
displayed.
Okay. This is very strange. A few questions, I don't know if they
will lead anywhere, but....
1) Are you using Wonder? (there have been some changes to Wonder's
version of NSArray lately and you never know....)
Yes, I'm using Wonder.
2) What Database are you using?
OpenBase
3) Which Database plugin?
4) If you're not using Wonder, what happens if you add ERExtensions
to your build path and move it to the top?
5) In exactly which way will Chuck make me feel like an idiot by
telling you exactly what's wrong in just one?
Dave
1. I'm using Wonder
2. OpenBase
3. Hmmm, plugin. :-) I don't specify one.
Here's another strange thing in the sql to me - I didn't notice it at
first. When requesting Job.approvers() why does the logged sql say:
(t0.priority = ? AND t0.emp_id = ?)
The relationship Job <->> Approver is joined on job_id, not emp_id. If
I run the sql that is being logged manually it definitely will not
return the right results. Then why is my app both return the right
results and logging the apparently incorrect sql?
Tim
I can group two qualifiers and use an EOAndQualifier and that
works, like so:
EOKeyValueQualifier
("approvers.employee",EOQualifier.QualifierOperatorEqual,
someEmployee)
EOKeyValueQualifier
("approvers.foo",EOQualifier.QualifierOperatorEqual, new Integer
(1))
But then I'm not leveraging the incredible work I've done to
use inheritance. :-) Does anyone have any idears why I am
seeing this problem?
Thanks for the help,
Tim
UCLA GSE&IS
Is Approver marked as Abstract in the model? How is the
primaryapprovers relationship modeled?
Yes Approver is abstract in the model. primaryapprovers and
delegateapprovers are both modeled as a to-many from Job with the
destination being PrimaryApprover, DelegateApprover respectfully.
It's a class property, allows nulls. Am I missing anything?
Chuck
Thanks Chuck.
Thanks for your help David.
Tim
_______________________________________________
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