Hi Simon, hi Bill,
I reverted all changes within trunk (sorry guys from the docu team).
I also released the existing 8 issues to this problem and the PDO ODBC
Adapter and set to to unassigned.
I will also create about 3-7 issues for the usecases we discussed and for
which no explicit issues were written.
If wished I can also delete the PDO ODBC Adapter from incubator.
I'm only sorry for the unnecessary time spent for the improvement of this
component.
Anyhow, if my help is appreciated again I would be willing to help.
Greetings
Thomas
I18N Team Leader
----- Original Message -----
From: "Simon Mundy" <[EMAIL PROTECTED]>
To: "Thomas Weidner" <[EMAIL PROTECTED]>
Cc: "Bill Karwin" <[EMAIL PROTECTED]>; "Zend Framework - General"
<fw-general@lists.zend.com>; <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2007 10:25 AM
Subject: Re: [fw-db] Re: [fw-general] Zend_Db_Select::where() malfunction
Hi Thomas
No offense taken! I am very aware of the work you're completing on
other projects and I'm grateful of the time you've already spent
solving the issue.
Outside of yours and my preferences for the progression of these
components I still think there's a need to make these kind of changes
outside of trunk - the incubator or lab would be a better place to
start so that the community doesn't get a shock when something changes
without much warning. Even if the final intention is to keep it as
before, if there's a period when it doesn't work as it did previously
(and even if it wasn't made readily apparent) I can understand some
noise if a component 'breaks' out of the blue when it is marked as
stable. Like I said, I won't disagree that it's been a bit of a
surprise for you as it wasn't documented or tested previously.
As it's provoked some feedback already I'm voting to put this back to
proposal stage for now, if only to get some more heads across the
problem.
You've noted that the Zend_Db_Bind idea I had wasn't to your liking
but I would contend that it provides:-
- Backward compatibility with no ambiguity to the method parameters
- A more solid and extensible way to introduce binding to multiple
placeholders
- Less reliance on the 'Select' component to perform a function that's
already the job of Zend_Db_Statement
I'll post the proposal and some existing code ASAP for feedback
Cheers
Hy Simon,
I also agree with Bill in that BC is a mandatory - unless the
community have sufficient time to be made aware of a major API change
for a full version release rather than a minor release.
I really don't see the problem.
The related changes were not commited to branch only to trunk
because I was not finished with coding, so the release would have
been untouched.
As general solution I reverted all changes from me related to
Zend_Db_Select and _Adapter.
If you want I could also revert the PDO ODBC Adapter.
I think this should finish the related discussion.
Don't get me wrong, but I have really enough work with other things
to be attacked about issues for changes which are not finished and
issues which have been cleared within usecases.
I'm sure we can come to a more graceful resolution of this
enhancement.
The idea was to have the handling for the placeholder like this:
Usecase 16:
->where("price in (?)", array(1,2,3,4));
// where price in (1, 2, 3, 4)
Usecase 17:
->where("price > ? and price in (?)", array (1,2,3,4));
// where price > 1 and price in (2, 3, 4)
Usecase 18:
->where("price in (?) and price like '?'", array(1,2,3,4));
// where price in (1, 2, 3, 4) and price like '?'
This would have solved all backward compatibility issues which have
been told and was the general idea about which I and Art wrote
yesterday.
And this is also why I am a little bit upset, because all are angry
about a solution which has not been completed for now.
The whole array management has not been coded for now as I already
wrote in the past.
I will reopen the already fixes issues and write new ones for the
behaviour we discussed within our usecases.
Greetings
Thomas
I18N Team Leader
----- Original Message ----- From: "Simon Mundy"
<[EMAIL PROTECTED]
>
To: "Thomas Weidner" <[EMAIL PROTECTED]>
Cc: "Bill Karwin" <[EMAIL PROTECTED]>; "Zend Framework - General"
<fw-general@lists.zend.com
>; <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2007 12:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Hi Thomas
In fairness I also didn't know of that usecase - however there is a
similar usage in Zend_Db_Table::find(). So it would seem to hold that
where one would exist the other would behave similarly - and since
Art
and Shekar have indicated that it did exist in that form I have no
reason to doubt it.
I also agree with Bill in that BC is a mandatory - unless the
community have sufficient time to be made aware of a major API change
for a full version release rather than a minor release.
You have a compelling argument that no tests/documentation exists and
that was obviously a major oversight.
I would like to acknowledge the time and effort you've already put
into the enhancements to the Select component and to see if somehow
this can still be integrated in a less divisive manner. Rather than
withdrawing the changes you've made already, would it be OK to
migrate
it to the Laboratory for the present so that the API changes can be
debated some more before it's re-introduced to the incubator? There's
too much good stuff in there to be wasted!
I'm sure we can come to a more graceful resolution of this
enhancement.
Cheers
Unit tests where not lacking...
I added docu and unit tests to all my changes. I ran all unit tests
before I did my commit.
And how should I receive backwards compatibility if there are no
tests and no documentation so people did not know that this even
exists ?
It's impossible because there is no way to test if a function
behaves the same as before... so new features are impossible if this
is true because every change does also change the behaviour and
could brake some undocumented, unexpected behaviour.
Option one is irrelevant... too complicated from users view.
Option two is complicated... multiple methods for where clauses
complicate the API. This is unpracticable.
Option three is not possible... it would brake usecases 7 to 15.
These usecases are solving problems which are actually not possible
with the old where behaviour.
As the possible solution from Art and me seems not good from you
point of view (it would solve all related problems and preserve
backwards compatibility) I think the best is that I revert all
changes which I made in the last two weeks and let the work/help on
Zend_Db be done by other ones. I am not the main author of this
component nor did I want to raise any problems with solving issues.
Greetings
Thomas
I18N Team Leader
----- Original Message ----- From: "Bill Karwin" <[EMAIL PROTECTED]>
To: <fw-general@lists.zend.com>
Sent: Wednesday, November 21, 2007 10:55 PM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Since ZF 1.0 was released the "Prime Directive" is to preserve
backward
compatibility if possible. This includes when resolving reported
bugs or
feature requests; the behavior of ZF 1.0 must be preserved for Zend
Framework's mission to be accomplished.
I understand that it is tempting to change the API and the behavior
to make
an elegant solution for a bug or feature request. But backward
compatibility is more important than elegance in most cases.
The test of backward compatibility is that the function behaves the
same,
given the same inputs and program state. It is irrelevant that the
functionality is missing from documentation or not exercised in
unit tests.
Zend_Db_Select unit tests do not include the test case of multiple
param
placeholders, but the documentation explicitly said that multiple
param
placeholders are not supported in a single call to where().
Supporting
multiple placeholders is new functionality. The lack of unit tests
for new
functionality is not a legitimate justification for breaking
backward
compatibility in existing functionality.
Note I mentioned "program state" above. One possible solution that
would
preserve backward-compatibility is that the component (in this case
Zend_Db_Select) is given an option to change the default behavior.
The
default behavior (that is, if the option is not specified by the
user)
should always be backward compatible. I wouldn't favor this
solution as
much as the options below.
A second possible solution is to create a new function, that has
the
behavior that you desire. For example whereMulti() which may
processes
multiple param placeholders, but does not support interpolating an
array
into a comma-separated list as the old where() method does. This
is better
that solution #1, but still complicates the API by adding new
methods for
both where() and whereOr().
A third possible solution -- which I recommend -- is to use
additional
arguments for param values, instead of a single array of values.
This would
support using an array for the list in an IN predicate, support
multiple
param placeholders, and also preserve backward compatibility:
where('a IN (?) AND b = ?', array(10, 20, 30), 'foo')
Yields:
WHERE a IN ('10', '20', '30') AND b = 'foo'
Regards,
Bill Karwin
--
View this message in context:
http://www.nabble.com/Zend_Db_Select%3A%3Awhere%28%29-malfunction-tf4842393s16154.html#a13886733
Sent from the Zend Framework mailing list archive at Nabble.com.
--
Simon Mundy | Director | PEPTOLAB
""" " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
Please support Movember today! Visit http://www.movember.com/au/donate
Registration number for Simon 160725
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
4124
http://www.peptolab.com
--
Simon Mundy | Director | PEPTOLAB
""" " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
Please support Movember today! Visit http://www.movember.com/au/donate
Registration number for Simon 160725
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654
4124
http://www.peptolab.com
