On 25 Apr 2015, at 11:40 pm, David Avendasora <[email protected]> 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! -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
