Re: ERXExistsQualifier
Re: ERXExistsQualifier
- Subject: Re: ERXExistsQualifier
- From: David Avendasora <email@hidden>
- Date: Sat, 25 Apr 2015 16:10:07 +0200
See below. Sent from my iPhone On Apr 24, 2015, at 11:52 AM, Paul Hoadley < email@hidden> wrote: Hi Dave,
On 24 Apr 2015, at 7:07 pm, David Avendasora < email@hidden> wrote: I've found several edge cases where the exist qualifier doesn't work because the SQL it generates is invalid - partly because the WebObjects JDBCPlugIn class has a bug that simply sets the table alias to t0 no matter what you do.
But there's good news! I've rewritten the qualifier from the ground up and determined the fix for the PlugIn that needs to be implemented in all the JDBCPlugIn plugins.
I believe it now works across any number relationships, including flattened and compound PK tables - but it no longer has the option to use IN clause instead of an EXISTS clause.
I'll go back to the room and document it a bit better and then release it into the wild.
That sounds great Dave. Some questions:
1. Are you planning on committing an actual update to ERXExistsQualifier? That would certainly be what I'd like to see. I think Wonder has way too many deprecated classes (and methods) and class variants—you're not planning on adding ERXExistsQualifier2, are you? :-)
Nope! I was thinking DaveExistsQualifier - I need the validation as I think I'm the only Dave at wowodc this year!
2. Assuming it's updating the existing class, will it be backwards-compatible? I make a reasonable amount of use of ERXExistsQualifier—will it just be a drop-in replacement?
Short answer: No.
Long answer: There are a couple weird things about ERXExistsQualifier: 1) It can create SQL implementing either "exists" or "in" subqueries. 2) There was already a pre-existing ERXQualifierInSubquery that also creates SQL "in" subqueries, but ERXExistsQualifier's "in" subquery feature does not use it.
I actually named my qualifier ERXQualifierExistsSubquery as it is a peer of ERXQualifierInSubquery. My plan is to deprecate ERXExistsQualifier as I think the re-implementation of the "in" subquery functionality in ERXExistsQualifier was well-intentioned, but ultimately a mistake. 3. Can you (or anyone) comment on any downside to not being able to generate EXISTS-based SQL? (I never use it, just curious.)
I'm not sure I understand what you are asking here... But I'd say that the biggest issue is that while the qualifier works just fine to filter arrays of EOs that are already in memory, it is completely unexpected that in certain situations it generates either invalid (bad) or valid-but-incorrect (far worse!) SQL when selecting out of the DB and you'll only find out about it at runtime. 4. You mention plugin updates being required—how much work will be involved there? Have you done any of it? Can we help? Will the changes to the plugins be isolated to using this qualifier? That is, is there any risk of breaking the plugins? (Personally I only care about PostgreSQL, but every plugin has some users.)
The change is very simple and only risky if anybody depends on all SQL table aliases being "t0" - which is entirely possible, but would likely be some hack to work around exactly this issue. A quick review of each plugin for "t0" Strings should identify any conflicting code.
|
_______________________________________________
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