Re: strange inheritance problem
On Jun 23, 2009, at 12:10 AM, Tim Worman wrote: One other avenue to pursue is whether EOKeyValueQualifier is suitable for the sort of query you are doing: EOKeyValueQualifier ("primaryapprovers.employee",EOQualifier.QualifierOperatorEqual, someEmployee) Maybe ERXExistsQualifier (EOKeyValueQualifier("employee",EOQualifier.QualifierOperatorEqual, someEmployee), "primaryapprovers") I just wanted to follow up and say that this contraption qualifier works. Thanks for a workable solution Chuck. If I ever make a WOWODC, I am now up to about 6 beers owed. I suspected that might be it. Several of the qualifiers only generate the correct SQL within a set of boundaries and none tell you when you stray outside. EOKeyValueQualifier and to-many relationships are often problematic. That is one of the reasons these other qualifiers were created. Chuck -- 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
Re: strange inheritance problem
Hello all: On Jun 19, 2009, at 1:14 PM, Chuck Hill wrote: On Jun 19, 2009, at 1:07 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
Re: strange inheritance problem
On Jun 19, 2009, at 1:10 PM, David Avendasora wrote: On Jun 19, 2009, at 3: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. Can you dig into the .plist files for the relationships and verify that they are really using the PKs and FKs that you think they are? Dave Yeah, I did. They are all using job_id as they should. Tim 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 t
Re: strange inheritance problem
On Jun 19, 2009, at 1:07 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 program
Re: strange inheritance problem
On Jun 19, 2009, at 3: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. Can you dig into the .plist files for the relationships and verify that they are really using the PKs and FKs that you think they are? Dave 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 relatio
Re: strange inheritance problem
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
Re: strange inheritance problem
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.
Re: strange inheritance problem
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 immediate
Re: strange inheritance problem
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? 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. 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 inh
Re: strange inheritance problem
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
Re: strange inheritance problem
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) 2) What Database are you using? 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 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 (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
Re: strange inheritance problem
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. 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 (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
Re: strange inheritance problem
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 ? 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? 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. ___ 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/webobjects%40avendasora.com This email sent to webobje...@avendasora.com ___ 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
Re: strange inheritance problem
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. When I log out the sql there is no mention in it of the foo attribute. 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. ___ 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
Re: strange inheritance problem
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. When I log out the sql there is no mention in it of the foo attribute. 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? Chuck -- 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