Re: ERXExistsQualifier
Re: ERXExistsQualifier
- Subject: Re: ERXExistsQualifier
- From: Paul Hoadley <email@hidden>
- Date: Sun, 26 Apr 2015 11:23:57 +0930
| On 25 Apr 2015, at 11:40 pm, David Avendasora <email@hidden> wrote:
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 knew it!
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.
Ah, OK. Cool. FWIW, I think that’s a great idea. So the short answer is no, it’s not a drop-in replacement, but it also won’t break anything anyone’s currently doing (other than flagging the use of a to-be-deprecated class) because you’re not touching the current ERXExistsQualifier.
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…
Sorry, that was a typo. I meant "not being able to generate IN-based SQL”. When I thought you were working on the existing class, I wondered what the downside would be of no longer being able to use it to create IN clauses. But you’ve cleared everything up.
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.
Cool. This is great work Dave, thanks for doing it!
|
_______________________________________________
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