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.
