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
