On Jun 19, 2009, at 12:43 PM, Chuck Hill wrote:
On Jun 19, 2009, at 12:08 PM, Tim Worman wrote:
On Jun 19, 2009, at 11:15 AM, Chuck Hill wrote:
Hi Tim,
On Jun 19, 2009, at 10:21 AM, Tim Worman wrote:
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:
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
That is not what I see. Another copy and paste error?
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.
Have you tried that to verify? Are you trying it on the _same_
database that the app is using?
Definitely the same database. I'm running locally in dev mode and
it is the only running database. In Entity Modeler the
relationships clearly have job_id as the join attribute.
Then why is my app both return the right results and logging the
apparently incorrect sql?
That is a good question. I am pretty sure that the logged SQL
should be exactly what is getting sent to the database. It has
been a while since I used OpenBase, but I think there is a way to
turn on SQL logging for the database. It would be good to compare
that with what EOF says.
OK, I think that the logging I'm seeing is the firing of faults for
other relationship targets of the Job I'm trying to load approvers
for. So, now I'm just trying to limit the logging to the
job.primaryapprovers() reqeust. I'm enabling and disabling the
logging immediately around that request and I'm not seeing anything
getting logged so I'm not sure how to simply capture that
transaction.
If you are not seeing anything, that means the fault has already
been fired.
For the life of me I cannot log out the relationship fetch no matter
how tricky I get to try and capture it.
Back to our regularly scheduled programming:
The problem still is that the subclass relationships are returning the
right results to my app so the problematic fetch I mentioned above
should work. Maybe what I should do is git branch and rebuild the
relationships and see what happens.
T
Chuck
I'd also quadruple check your model. Is there a back pointing
relationship from Approver to Job? Is that relationship also on
the sub-classes in the model?
Chuck
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
--
Chuck Hill Senior Consultant / VP Development
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
--
Chuck Hill Senior Consultant / VP Development
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
