Hy Simon,
> Perhaps it should stay that way?
It would stay that way... the idea was to have all supported
as before, and
add new funtionality to have where clauses been created
which are not
possible until now.
See Usecases 16 and 17:
16)
where("price in (?)", array(1,2,3,4));
// where price in (1, 2, 3, 4)
17)
where("price > ? and price in (?)", array
(1,2,3,4));
// where price > 1 and price in (2, 3, 4)
> For the new functionality suggested by Thomas we could
instead create
> a new Db component - Zend_Db_Bind which operates in a
similar fashion
> to Zend_Db_Expr.
In my eyes this would complicate the API and being
unnecessary because there
is already a simple solution with the existing API.
And it does not solve the problems which would have been
solved with the not
finished changeset.
Later binding is already supported by the API so there would
be no reason to
create a own class for that.
What was written within the related issue is instant value
binding and a
combination of instant and later binding.
Greetings
Thomas
I18N Team Leader
----- Original Message -----
From: "Simon Mundy" <simon.mundy peptolab.com>
To: "Thomas Weidner" <thomas.weidnergmx.at>
Cc: "Bill Karwin" <billkarwin.com>; "Zend
Framework - General"
<fw-generallists.zend.com>; <fw-dblists.zend.com>
Sent: Thursday, November 22, 2007 5:33 AM
Subject: Re: [fw-general] Zend_Db_Select::where()
malfunction
> Hi Thomas, Bill, all
>
> I've just had another thought...
>
> Currently the API allows for immediate substitution -
the ? takes the
> value of the second parameter and it is quoted before
being added to
> the select object.
>
> Perhaps it should stay that way?
>
> For the new functionality suggested by Thomas we could
instead create
> a new Db component - Zend_Db_Bind which operates in a
similar fashion
> to Zend_Db_Expr.
>
> This would allow for more correct late binding and also
dispense with
> the Zend_Db_Select object performing tasks that can
already be solved
> by Zend_Db_Statement.
>
> So existing usage is:-
>
> $select->where('id = ?', 3); // WHERE id = 3
> $select->where('id IN (?)', array('a', 'b', 'c'));
// WHERE id IN
> ('a', 'b', 'c');
>
> And new usage for the Zend_Db_Bind object would be:-
>
> $select->where(new Zend_Db_Bind('column = :first AND
column2
> = :second', array('first' => 2, 'second' => 3)));
// Not evaluated
> until statement called
> $select->where(new Zend_Db_Bind('column = ? AND
other = ?', array(1,
> 140)));
>
> To my mind this would solve the problem of substitution
more cleanly
> and still allow the existing API to live comfortably.
>
> Thoughts?
>
>> 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" <billkarwin.com>
>> To: <fw-generallists.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.nabbl
e.com/Zend_Db_Select%3A%3Awhere%28%29-malfunction-tf4842393s
16154.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
>
>
|