Re: [fw-general] Zend_Db_Select::where() malfunction
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for such
clauses.
I am actually also working on a BEWTEEN function which adds between to be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 8:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
This feature of imploding an array of values into a single place-holder
was
there from the the days of ZF v0.1.5 or earlier. My code was working fine
all these days. There were code examples in the documentation that showed
how an array would be imploded into the SQL using where(). I even created
an
issue in the past to avoid quoting numeric values in the resulting SQL's
array (look for the issue that reads: quote() quotes numeric values a
bug
that was attributed to PDO). I just did a diff on Select.php between the
current SVN and 1.0.2 and noticed that where() method actually invokes and
delegates to _where() in the current SVN whereas there is no _where()
method
in 1.0.2. My same code with ZF 1.0.2 works fine as expected but not with
the
latest SVN update.
If this is not supported, what's the syntax for the expected SQL? I need
to
generate a where clause as under:
WHERE status IN ( 'A', 'I' )
Thanks,
On 11/20/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Hy Shekar,
this is not supported, and it was not supported in the past.
Because ? is a placeholder for only ONE variable.
And you gave two within your array :-)
Actually I am working on a array integration which adds several new
features
to where.
But the behaviour you are expecting would break things with other new
where
features.
For now it is not planned to support such a use case.
Btw: Before my improvement several days ago even the first variable would
not have been integrated.
That the array value is inserted for a placeholder is also one of the new
features :-)
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Zend Framework General fw-general@lists.zend.com
Sent: Tuesday, November 20, 2007 10:55 AM
Subject: [fw-general] Zend_Db_Select::where() malfunction
Bill,
I downloaded the latest SVN today and noticed a strange behavior with
the
select component:
$select-where( 'status IN ( ? )', array( 'A', 'I' ));
SQL generated:
WHERE status IN ( 'A' )
SQL expected:
WHERE status IN ( 'A', 'I' )
Re: [fw-general] Zend_Db_Select::where() malfunction
Shekar,
to get my snippet working with previous versions you would just have to add
a version check...
if (Zend_Version::compareVersions('1.0.2') 0) {
// change where
}
or you wait for the issue to be solved...
1.0.4 I think as in 4 days the new release comes out.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 11:02 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results -
it generates SQL imploding all the array values into a single placeholder
as
expected. The documentation used to have this usage listed but now it
seems
to have been removed. The code snipped you gave generated the following
SQL
with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome but
I
thought they would be backwards compatible - I had to revert to 1.0.2 :(
The old code used to be generic and would apply to both - a normal where
clause with a boolean operator or an IN operator because it used to
implode
the array into a list of values to replace a single placeholder but the
new
enhancements need IN-operators handled differently using arrays and
multiple
placeholders. I guess having a separate in() function for such expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single
placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for
such
clauses.
I am actually also working on a BEWTEEN function which adds between to be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue
for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 8:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
This feature of imploding an array of values into a single place-holder
was
there from the the days of ZF v0.1.5 or earlier. My code was working
fine
all these days. There were code examples in the documentation that
showed
how an array would be imploded into the SQL using where(). I even
created
an
issue in the past to avoid quoting numeric values in the resulting
SQL's
array (look for the issue that reads: quote() quotes numeric values a
bug
that was attributed to PDO). I just did a diff on Select.php between
the
current SVN and 1.0.2 and noticed that where() method actually invokes
and
delegates to _where() in the current SVN whereas there is no _where()
method
in 1.0.2. My same code with ZF 1.0.2 works fine as expected but not
with
the
latest SVN update.
If this is not supported, what's the syntax for the expected SQL? I
need
to
generate a where clause as under:
WHERE status IN ( 'A', 'I' )
Thanks,
On 11/20/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Hy Shekar,
this is not supported, and it was not supported in the past.
Because ? is a placeholder for only ONE variable.
And you gave two within your array :-)
Actually I am working on a array integration which adds several new
features
to where.
But the behaviour you are expecting would break things with other new
where
features.
For now it is not planned to support such a use case.
Btw: Before my improvement several days ago even the first variable
would
not have been integrated.
That the array value is inserted for a placeholder is also one of the
new
features :-)
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Zend Framework General fw-general@lists.zend.com
Sent: Tuesday, November 20, 2007 10:55 AM
Subject: [fw-general] Zend_Db_Select::where() malfunction
Bill,
I downloaded the latest SVN today
Re: [fw-general] NT Authentication Pdo MSSQL
Hi Terry, My apologies for the late reply... I ran into this issue with PDO as well. I was able to work around it by using the PDO ODBC adapter, where only the DSN is required. IIRC, I got NT Authentication to work like that, however, I haven't actually done this since shortly after PHP 5 first came out, so YMMV. :) Note that the PHP manual recommends using ODBC to connect to MS SQL, rather than the DBLIB adapter. Also, unfortunately, there's no Zend_Db_Adapter_Pdo_Odbc yet. Regards, Bryce Lohr Terry Shipclark wrote: Hello All, I am currently attempting to use NT Authentication with the Zend Framework. Currently with Pdo there is no way of not passing a username/password. I know the connection works as we currently use mssql_pconnect from the same server to connect using NT Authentication. I was just wondering if anyone else has had similar experiences with better results, as before I can truly begin developing a full fledged application with Zend Framework. Thanks alot in advance Terry
Re: [fw-general] Zend_Db_Select::where() malfunction
I guess the new method should be named inWhere().
On 11/21/07, Shekar C Reddy [EMAIL PROTECTED] wrote:
Thomas,
I encourage you to test the where() method with v1.0.2 and see the results
- it generates SQL imploding all the array values into a single placeholder
as expected. The documentation used to have this usage listed but now it
seems to have been removed. The code snipped you gave generated the
following SQL with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome but
I thought they would be backwards compatible - I had to revert to 1.0.2 :(
The old code used to be generic and would apply to both - a normal where
clause with a boolean operator or an IN operator because it used to implode
the array into a list of values to replace a single placeholder but the new
enhancements need IN-operators handled differently using arrays and multiple
placeholders. I guess having a separate in() function for such expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single
placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for
such
clauses.
I am actually also working on a BEWTEEN function which adds between to
be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue
for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 8:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
This feature of imploding an array of values into a single
place-holder
was
there from the the days of ZF v0.1.5 or earlier. My code was working
fine
all these days. There were code examples in the documentation that
showed
how an array would be imploded into the SQL using where(). I even
created
an
issue in the past to avoid quoting numeric values in the resulting
SQL's
array (look for the issue that reads: quote() quotes numeric values
a
bug
that was attributed to PDO). I just did a diff on Select.php between
the
current SVN and 1.0.2 and noticed that where() method actually invokes
and
delegates to _where() in the current SVN whereas there is no _where()
method
in 1.0.2. My same code with ZF 1.0.2 works fine as expected but not
with
the
latest SVN update.
If this is not supported, what's the syntax for the expected SQL? I
need
to
generate a where clause as under:
WHERE status IN ( 'A', 'I' )
Thanks,
On 11/20/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Hy Shekar,
this is not supported, and it was not supported in the past.
Because ? is a placeholder for only ONE variable.
And you gave two within your array :-)
Actually I am working on a array integration which adds several new
features
to where.
But the behaviour you are expecting would break things with other new
where
features.
For now it is not planned to support such a use case.
Btw: Before my improvement several days ago even the first variable
would
not have been integrated.
That the array value is inserted for a placeholder is also one of the
new
features :-)
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Zend Framework General fw-general@lists.zend.com
Sent: Tuesday, November 20, 2007 10:55 AM
Subject: [fw-general] Zend_Db_Select::where() malfunction
Bill,
I downloaded the latest SVN today and noticed a strange behavior
with
the
select component:
$select-where( 'status IN ( ? )', array( 'A', 'I' ));
SQL generated:
WHERE status IN ( 'A' )
SQL expected:
Re: [fw-general] Zend_Db_Select::where() malfunction
Please ignore the new suggested name. It is a part of the where clause
[where()/orWhere()] and so, in() would be ideal:
$select-where($select-in( ... ));
$select-orWhere( $select-in( ... ));
Thanks
On 11/21/07, Shekar C Reddy [EMAIL PROTECTED] wrote:
I guess the new method should be named inWhere().
On 11/21/07, Shekar C Reddy [EMAIL PROTECTED] wrote:
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results - it generates SQL imploding all the array values into a single
placeholder as expected. The documentation used to have this usage listed
but now it seems to have been removed. The code snipped you gave generated
the following SQL with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome
but I thought they would be backwards compatible - I had to revert to
1.0.2 :( The old code used to be generic and would apply to both - a
normal where clause with a boolean operator or an IN operator because it
used to implode the array into a list of values to replace a single
placeholder but the new enhancements need IN-operators handled differently
using arrays and multiple placeholders. I guess having a separate in()
function for such expressions is more ideal and desired at the component
level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single
placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for
such
clauses.
I am actually also working on a BEWTEEN function which adds between to
be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue
for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 8:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
This feature of imploding an array of values into a single
place-holder
was
there from the the days of ZF v0.1.5 or earlier. My code was working
fine
all these days. There were code examples in the documentation that
showed
how an array would be imploded into the SQL using where(). I even
created
an
issue in the past to avoid quoting numeric values in the resulting
SQL's
array (look for the issue that reads: quote() quotes numeric
values a
bug
that was attributed to PDO). I just did a diff on Select.php between
the
current SVN and 1.0.2 and noticed that where() method actually
invokes and
delegates to _where() in the current SVN whereas there is no
_where()
method
in 1.0.2. My same code with ZF 1.0.2 works fine as expected but not
with
the
latest SVN update.
If this is not supported, what's the syntax for the expected SQL? I
need
to
generate a where clause as under:
WHERE status IN ( 'A', 'I' )
Thanks,
On 11/20/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Hy Shekar,
this is not supported, and it was not supported in the past.
Because ? is a placeholder for only ONE variable.
And you gave two within your array :-)
Actually I am working on a array integration which adds several new
features
to where.
But the behaviour you are expecting would break things with other
new
where
features.
For now it is not planned to support such a use case.
Btw: Before my improvement several days ago even the first variable
would
not have been integrated.
That the array value is inserted for a placeholder is also one of
the new
features :-)
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To:
Re: [fw-general] NT Authentication Pdo MSSQL
This is wrong... Actually I made a PDO ODBC Adapter. You can find it within the incubator. Greetings Thomas I18N Team Leader - Original Message - From: Bryce Lohr [EMAIL PROTECTED] To: Terry Shipclark [EMAIL PROTECTED]; fw-general@lists.zend.com Sent: Wednesday, November 21, 2007 3:13 PM Subject: Re: [fw-general] NT Authentication Pdo MSSQL Hi Terry, My apologies for the late reply... I ran into this issue with PDO as well. I was able to work around it by using the PDO ODBC adapter, where only the DSN is required. IIRC, I got NT Authentication to work like that, however, I haven't actually done this since shortly after PHP 5 first came out, so YMMV. :) Note that the PHP manual recommends using ODBC to connect to MS SQL, rather than the DBLIB adapter. Also, unfortunately, there's no Zend_Db_Adapter_Pdo_Odbc yet. Regards, Bryce Lohr Terry Shipclark wrote: Hello All, I am currently attempting to use NT Authentication with the Zend Framework. Currently with Pdo there is no way of not passing a username/password. I know the connection works as we currently use mssql_pconnect from the same server to connect using NT Authentication. I was just wondering if anyone else has had similar experiences with better results, as before I can truly begin developing a full fledged application with Zend Framework. Thanks alot in advance Terry
Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
Don't take this the wrong way but these casual massive changes to the way
existing code works is the reason why I stopped using Zend_Db back in the .8
days. By taking away the array imploding functionality you have just broken
a considerable amount of existing code. Code written in accordance with the
published documentation.
Your use case rational: where(price ? and price = ?, array(2, 10));
can already be handled by calling where twice.
Did you talk to anybody before deciding to break existing behavior? If I
was still using Zend_Db then I'd be pretty upset to have my queries broken
without warning and for no particular reason. Especially since it appears
you plan on delivering these last minute changes without offering a useful
alternative.
Art
Thomas Weidner-2 wrote:
Shekar,
to get my snippet working with previous versions you would just have to
add
a version check...
if (Zend_Version::compareVersions('1.0.2') 0) {
// change where
}
or you wait for the issue to be solved...
1.0.4 I think as in 4 days the new release comes out.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 11:02 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results -
it generates SQL imploding all the array values into a single placeholder
as
expected. The documentation used to have this usage listed but now it
seems
to have been removed. The code snipped you gave generated the following
SQL
with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome
but
I
thought they would be backwards compatible - I had to revert to 1.0.2 :(
The old code used to be generic and would apply to both - a normal where
clause with a boolean operator or an IN operator because it used to
implode
the array into a list of values to replace a single placeholder but the
new
enhancements need IN-operators handled differently using arrays and
multiple
placeholders. I guess having a separate in() function for such
expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single
placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for
such
clauses.
I am actually also working on a BEWTEEN function which adds between to
be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue
for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 8:28 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
This feature of imploding an array of values into a single
place-holder
was
there from the the days of ZF v0.1.5 or earlier. My code was working
fine
all these days. There were code examples in the documentation that
showed
how an array would be imploded into the SQL using where(). I even
created
an
issue in the past to avoid quoting numeric values in the resulting
SQL's
array (look for the issue that reads: quote() quotes numeric values
a
bug
that was attributed to PDO). I just did a diff on Select.php between
the
current SVN and 1.0.2 and noticed that where() method actually invokes
and
delegates to _where() in the current SVN whereas there is no _where()
method
in 1.0.2. My same code with ZF 1.0.2 works fine as expected but not
with
the
latest SVN update.
If this is not supported, what's the syntax for the expected SQL? I
need
to
generate a where clause as under:
WHERE status IN ( 'A', 'I' )
Thanks,
On 11/20/07, Thomas Weidner [EMAIL
Re: [fw-general] Zend_Db_Select::where() malfunction
Art,
as I said in past we reviewed what was written within the documentation and
within the testbed.
The usecases did not brake anyone of the behaviour mentioned there.
Then we looked over the opened issues and discussed about the additional
usecases we want to support.
This mentioned usecase with one array integrated in one placeholder is
actually not supported and from my understanding of the documentation it was
not in the past.
The change itself was discussed within the dev team and with simon.
I was just the one who made the work.
If this is problematic I would also accept to reject my help and let all
Zend_Db issues as they were before.
I would be willing to redo my changes, delete the new features already done
and not implement the additional features which are already issued.
Please ask darby and simon how we should behave.
It would be nice if you give me the related documentation with the example
or text where you found the mentioned array behaviour.
Just give file and svn to check for us where we oversee this usecase.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Art Hundiak [EMAIL PROTECTED]
To: fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 4:18 PM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
Don't take this the wrong way but these casual massive changes to the way
existing code works is the reason why I stopped using Zend_Db back in the
.8
days. By taking away the array imploding functionality you have just
broken
a considerable amount of existing code. Code written in accordance with
the
published documentation.
Your use case rational: where(price ? and price = ?, array(2, 10));
can already be handled by calling where twice.
Did you talk to anybody before deciding to break existing behavior? If I
was still using Zend_Db then I'd be pretty upset to have my queries broken
without warning and for no particular reason. Especially since it appears
you plan on delivering these last minute changes without offering a useful
alternative.
Art
Thomas Weidner-2 wrote:
Shekar,
to get my snippet working with previous versions you would just have to
add
a version check...
if (Zend_Version::compareVersions('1.0.2') 0) {
// change where
}
or you wait for the issue to be solved...
1.0.4 I think as in 4 days the new release comes out.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 11:02 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results -
it generates SQL imploding all the array values into a single
placeholder
as
expected. The documentation used to have this usage listed but now it
seems
to have been removed. The code snipped you gave generated the following
SQL
with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome
but
I
thought they would be backwards compatible - I had to revert to 1.0.2 :(
The old code used to be generic and would apply to both - a normal where
clause with a boolean operator or an IN operator because it used to
implode
the array into a list of values to replace a single placeholder but the
new
enhancements need IN-operators handled differently using arrays and
multiple
placeholders. I guess having a separate in() function for such
expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I did my commit.
Actually, giving an array as input would result in each single
placeholder
to be replaced.
where(price ? and price = ?, array(2, 10));
becomes
where (price 2 and price = 10)
This is the reason why the automatic imploding does not work anymore.
Principially there are several ways:
You could for example do the following:
$array = array(2,10,14,20);
$addwhere = ;
for($i = 1; $i count($array); ++$i) {
$addwhere .= , ?;
}
$where = price IN (?. $addwhere.);
$db-where($where, $array);
In my eyes it would be better to have a own IN function avaiable for
such
clauses.
I am actually also working on a BEWTEEN function which adds between to
be
avaiable.
So eighter you use a the codesnippet I gave you or you add a new issue
for
creating a IN function which handles the IN within the where clause.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL
[fw-general] Forwarding with POST.
Before I dive into it, I'll admit to being a bit weak in the whole request/response flow, so bear with me if this is slightly obtuse. I've got an account creation page that works through one module. After account creation, I want to forward that user to my Auth controller, login action, which accepts POSTed email/password for validation. (I set up the authentication according to Akrabat's tutorial at http://akrabat.com/zend-auth-tutorial/) I'm not sure how to forward the user to the login action while simultaneously posting the email and password. Thanks in advance, kabel
Re: [fw-general] Forwarding with POST.
I think the only way to do this would be to create an HTML page with a form and some javascript that would perform a submit() when the page loads. This is dangerous though because you would have to embed the username/password or some sort of key/hash as a hidden form field. On Nov 21, 2007 8:59 AM, kabel [EMAIL PROTECTED] wrote: Before I dive into it, I'll admit to being a bit weak in the whole request/response flow, so bear with me if this is slightly obtuse. I've got an account creation page that works through one module. After account creation, I want to forward that user to my Auth controller, login action, which accepts POSTed email/password for validation. (I set up the authentication according to Akrabat's tutorial at http://akrabat.com/zend-auth-tutorial/) I'm not sure how to forward the user to the login action while simultaneously posting the email and password. Thanks in advance, kabel -- Michael DePetrillo [EMAIL PROTECTED] Mobile: (858) 761-1605 AIM: klassicd www.michaeldepetrillo.com
Re: [fw-general] Forwarding with POST.
Hi If you simply forward (/$this-_forward()/), then all the POST-data remains. A redirect (/$this-_redirect()/ or per redirector-helper) is a new request made by the browser and regulary there is no way to perform such a redirect with POST-data, but i dont see any cause to do this. You are able to login the user within the new user acceptet when the account is created. Or you just forward, even its not as clean as a redirection ;) kabel schrieb: Before I dive into it, I'll admit to being a bit weak in the whole request/response flow, so bear with me if this is slightly obtuse. I've got an account creation page that works through one module. After account creation, I want to forward that user to my Auth controller, login action, which accepts POSTed email/password for validation. (I set up the authentication according to Akrabat's tutorial at http://akrabat.com/zend-auth-tutorial/) I'm not sure how to forward the user to the login action while simultaneously posting the email and password. Thanks in advance, kabel
Re: [fw-general] Zend_Db_Select::where() malfunction
Zend 0.8.0 had the use of where IN (?) array documented. As well as previous
versions.
Zend 0.9.0 did not have it documented
Zend 0.9.1 was the first release with Zend_Db_Select unit test cases and, as
you say, did not have an array test or any tests with multiple ? place
holders
Zend 1.0.2 Zend_Db_Select source code has
/**
* Adds a WHERE condition to the query by AND.
*
* If a value is passed as the second param, it will be quoted
* and replaced into the condition wherever a question-mark
* appears. Array values are quoted and comma-separated.
I'm certainly not asking you to roll back all your changes. But is a point
release really the best time for something like this?
Perhaps, as a compromise, you could count the number of ? place holders and,
if 1, then keep the old behavior.
Thomas Weidner-2 wrote:
Art,
as I said in past we reviewed what was written within the documentation
and
within the testbed.
The usecases did not brake anyone of the behaviour mentioned there.
Then we looked over the opened issues and discussed about the additional
usecases we want to support.
This mentioned usecase with one array integrated in one placeholder is
actually not supported and from my understanding of the documentation it
was
not in the past.
The change itself was discussed within the dev team and with simon.
I was just the one who made the work.
If this is problematic I would also accept to reject my help and let all
Zend_Db issues as they were before.
I would be willing to redo my changes, delete the new features already
done
and not implement the additional features which are already issued.
Please ask darby and simon how we should behave.
It would be nice if you give me the related documentation with the example
or text where you found the mentioned array behaviour.
Just give file and svn to check for us where we oversee this usecase.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Art Hundiak [EMAIL PROTECTED]
To: fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 4:18 PM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
Don't take this the wrong way but these casual massive changes to the way
existing code works is the reason why I stopped using Zend_Db back in the
.8
days. By taking away the array imploding functionality you have just
broken
a considerable amount of existing code. Code written in accordance with
the
published documentation.
Your use case rational: where(price ? and price = ?, array(2, 10));
can already be handled by calling where twice.
Did you talk to anybody before deciding to break existing behavior? If I
was still using Zend_Db then I'd be pretty upset to have my queries
broken
without warning and for no particular reason. Especially since it
appears
you plan on delivering these last minute changes without offering a
useful
alternative.
Art
Thomas Weidner-2 wrote:
Shekar,
to get my snippet working with previous versions you would just have to
add
a version check...
if (Zend_Version::compareVersions('1.0.2') 0) {
// change where
}
or you wait for the issue to be solved...
1.0.4 I think as in 4 days the new release comes out.
Greetings
Thomas
I18N Team Leader
- Original Message -
From: Shekar C Reddy [EMAIL PROTECTED]
To: Thomas Weidner [EMAIL PROTECTED]
Cc: Zend Framework General fw-general@lists.zend.com
Sent: Wednesday, November 21, 2007 11:02 AM
Subject: Re: [fw-general] Zend_Db_Select::where() malfunction
Thomas,
I encourage you to test the where() method with v1.0.2 and see the
results -
it generates SQL imploding all the array values into a single
placeholder
as
expected. The documentation used to have this usage listed but now it
seems
to have been removed. The code snipped you gave generated the following
SQL
with 1.0.2:
price IN (2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20, 2, 10, 14, 20)
and the following SQL with the current SVN:
price IN (2, 10, 14, 20)
indicating they are generating different SQL. Enhancements are welcome
but
I
thought they would be backwards compatible - I had to revert to 1.0.2
:(
The old code used to be generic and would apply to both - a normal
where
clause with a boolean operator or an IN operator because it used to
implode
the array into a list of values to replace a single placeholder but the
new
enhancements need IN-operators handled differently using arrays and
multiple
placeholders. I guess having a separate in() function for such
expressions
is more ideal and desired at the component level.
Here is the issue to get started:
http://framework.zend.com/issues/browse/ZF-2223
Keep up the good work!
On 11/21/07, Thomas Weidner [EMAIL PROTECTED] wrote:
Shekar,
actually the documentation does not mention this usage.
And there are also no testcases.
All testcases have approved before I
Re: [fw-general] NT Authentication Pdo MSSQL
Does this require any changes to the php installation. Although I do believe that I may have enough pull to get pdo odbc support added to the server, this may take some time. I am not at a computer right now, however if I recall correctly odbc wasn't listed as one of the pdo drivers availqable. If it was just a matter of dropping in a dll, or including it in the php.ini then that would probably fairly simple Wow that was long winded, and thank you both for the reponses, I almost gave up on zf because of this issue. Terry Sent on the TELUS Mobility network with BlackBerry -Original Message- From: Thomas Weidner [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 16:09:31 To:Bryce Lohr [EMAIL PROTECTED],Terry Shipclark [EMAIL PROTECTED],fw-general@lists.zend.com Subject: Re: [fw-general] NT Authentication Pdo MSSQL This is wrong... Actually I made a PDO ODBC Adapter. You can find it within the incubator. Greetings Thomas I18N Team Leader - Original Message - From: Bryce Lohr [EMAIL PROTECTED] To: Terry Shipclark [EMAIL PROTECTED]; fw-general@lists.zend.com Sent: Wednesday, November 21, 2007 3:13 PM Subject: Re: [fw-general] NT Authentication Pdo MSSQL Hi Terry, My apologies for the late reply... I ran into this issue with PDO as well. I was able to work around it by using the PDO ODBC adapter, where only the DSN is required. IIRC, I got NT Authentication to work like that, however, I haven't actually done this since shortly after PHP 5 first came out, so YMMV. :) Note that the PHP manual recommends using ODBC to connect to MS SQL, rather than the DBLIB adapter. Also, unfortunately, there's no Zend_Db_Adapter_Pdo_Odbc yet. Regards, Bryce Lohr Terry Shipclark wrote: Hello All, I am currently attempting to use NT Authentication with the Zend Framework. Currently with Pdo there is no way of not passing a username/password. I know the connection works as we currently use mssql_pconnect from the same server to connect using NT Authentication. I was just wondering if anyone else has had similar experiences with better results, as before I can truly begin developing a full fledged application with Zend Framework. Thanks alot in advance Terry
Re: [fw-general] NT Authentication Pdo MSSQL
I made this PDO ODBC Adapter because I had to connect to MSDE on a Win2000 Machine. I ran it successfully with systemdsn and unconfigured Msde connections with success. Of course I can not guarantee that all things are working, but that's the reason why it's still in the incubator. It should help you with your problem. Feel free to report success or failures... the related issue is ZF-905. Greetings Thomas I18N Team Leader - Original Message - From: [EMAIL PROTECTED] To: fw-general@lists.zend.com Sent: Wednesday, November 21, 2007 9:16 PM Subject: Re: [fw-general] NT Authentication Pdo MSSQL Does this require any changes to the php installation. Although I do believe that I may have enough pull to get pdo odbc support added to the server, this may take some time. I am not at a computer right now, however if I recall correctly odbc wasn't listed as one of the pdo drivers availqable. If it was just a matter of dropping in a dll, or including it in the php.ini then that would probably fairly simple Wow that was long winded, and thank you both for the reponses, I almost gave up on zf because of this issue. Terry Sent on the TELUS Mobility network with BlackBerry -Original Message- From: Thomas Weidner [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 16:09:31 To:Bryce Lohr [EMAIL PROTECTED],Terry Shipclark [EMAIL PROTECTED],fw-general@lists.zend.com Subject: Re: [fw-general] NT Authentication Pdo MSSQL This is wrong... Actually I made a PDO ODBC Adapter. You can find it within the incubator. Greetings Thomas I18N Team Leader - Original Message - From: Bryce Lohr [EMAIL PROTECTED] To: Terry Shipclark [EMAIL PROTECTED]; fw-general@lists.zend.com Sent: Wednesday, November 21, 2007 3:13 PM Subject: Re: [fw-general] NT Authentication Pdo MSSQL Hi Terry, My apologies for the late reply... I ran into this issue with PDO as well. I was able to work around it by using the PDO ODBC adapter, where only the DSN is required. IIRC, I got NT Authentication to work like that, however, I haven't actually done this since shortly after PHP 5 first came out, so YMMV. :) Note that the PHP manual recommends using ODBC to connect to MS SQL, rather than the DBLIB adapter. Also, unfortunately, there's no Zend_Db_Adapter_Pdo_Odbc yet. Regards, Bryce Lohr Terry Shipclark wrote: Hello All, I am currently attempting to use NT Authentication with the Zend Framework. Currently with Pdo there is no way of not passing a username/password. I know the connection works as we currently use mssql_pconnect from the same server to connect using NT Authentication. I was just wondering if anyone else has had similar experiences with better results, as before I can truly begin developing a full fledged application with Zend Framework. Thanks alot in advance Terry
Re: [fw-general] NT Authentication Pdo MSSQL
Thank you for the clarification on this, Thomas. I was unaware of your adapter in the incubator. Regards, Bryce Lohr Thomas Weidner wrote: This is wrong... Actually I made a PDO ODBC Adapter. You can find it within the incubator. Greetings Thomas I18N Team Leader - Original Message - From: Bryce Lohr [EMAIL PROTECTED] To: Terry Shipclark [EMAIL PROTECTED]; fw-general@lists.zend.com Sent: Wednesday, November 21, 2007 3:13 PM Subject: Re: [fw-general] NT Authentication Pdo MSSQL Hi Terry, My apologies for the late reply... I ran into this issue with PDO as well. I was able to work around it by using the PDO ODBC adapter, where only the DSN is required. IIRC, I got NT Authentication to work like that, however, I haven't actually done this since shortly after PHP 5 first came out, so YMMV. :) Note that the PHP manual recommends using ODBC to connect to MS SQL, rather than the DBLIB adapter. Also, unfortunately, there's no Zend_Db_Adapter_Pdo_Odbc yet. Regards, Bryce Lohr Terry Shipclark wrote: Hello All, I am currently attempting to use NT Authentication with the Zend Framework. Currently with Pdo there is no way of not passing a username/password. I know the connection works as we currently use mssql_pconnect from the same server to connect using NT Authentication. I was just wondering if anyone else has had similar experiences with better results, as before I can truly begin developing a full fledged application with Zend Framework. Thanks alot in advance Terry
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.
[fw-general] undefined method DB_mssql::lastInsertId() ??
Hello! I'm constantly running in to these types of issues. I must be doing
something fundamentally wrong. I've instantiated a database connection like
so:
// --
$dsn = $config-dbadaptor . :// // Build a DSN string (Data Source
Name)
. $config-username . :// Required by DB::connect()
. $config-password . @
. $config-host . /
. $config-dbname;
$db = DB::connect($dsn, TRUE);
if (DB::isError($db)) {
die($db-getMessage());
}
$this-db = $db;
// --
Later in my code, I do something like this:
// --
$sql = INSERT INTO $table_name ( . implode(',',$transformed_keys) . ')
VALUES ( ' . implode(',',$values) . ' ) ';
$result = $this-db-query($sql);
$id = $this-db-lastInsertId();
// --
Unfortunately, I get the error, undefined method DB_mssql::lastInsertId().
What am I doing wrong?
Thanks!
- Bret
--
View this message in context:
http://www.nabble.com/undefined-method-DB_mssql%3A%3AlastInsertId%28%29tf4853199s16154.html#a13887470
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] undefined method DB_mssql::lastInsertId() ??
DB::connect looks like a PEAR factory method - are you sure you're
using Zend Framework? If not, you'd need to post to a PEAR mailing list.
Hello! I'm constantly running in to these types of issues. I must be
doing something fundamentally wrong. I've instantiated a database
connection like so:
//
--
$dsn = $config-dbadaptor . :// // Build a DSN string (Data
Source Name)
. $config-username . :// Required by DB::connect()
. $config-password . @
. $config-host . /
. $config-dbname;
$db = DB::connect($dsn, TRUE);
if (DB::isError($db)) {
die($db-getMessage());
}
$this-db = $db;
//
--
Later in my code, I do something like this:
//
--
$sql = INSERT INTO $table_name ( . implode(',',
$transformed_keys) . ') VALUES ( ' . implode(',',$values) . ' ) ';
$result = $this-db-query($sql);
$id = $this-db-lastInsertId();
//
--
Unfortunately, I get the error, undefined method
DB_mssql::lastInsertId(). What am I doing wrong?
Thanks!
- Bret
View this message in context: undefined method
DB_mssql::lastInsertId() ??
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
Re: [fw-general] Zend_Db_Select::where() malfunction
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.
Re: [fw-general] undefined method DB_mssql::lastInsertId() ??
Woops! Ha ha ha. I'm an idiot. Sorry about that. I got confused about
which database library I was using. Thanks!
Simon Mundy wrote:
DB::connect looks like a PEAR factory method - are you sure you're
using Zend Framework? If not, you'd need to post to a PEAR mailing list.
Hello! I'm constantly running in to these types of issues. I must be
doing something fundamentally wrong. I've instantiated a database
connection like so:
//
--
$dsn = $config-dbadaptor . :// // Build a DSN string (Data
Source Name)
. $config-username . :// Required by DB::connect()
. $config-password . @
. $config-host . /
. $config-dbname;
$db = DB::connect($dsn, TRUE);
if (DB::isError($db)) {
die($db-getMessage());
}
$this-db = $db;
//
--
Later in my code, I do something like this:
//
--
$sql = INSERT INTO $table_name ( . implode(',',
$transformed_keys) . ') VALUES ( ' . implode(',',$values) . ' ) ';
$result = $this-db-query($sql);
$id = $this-db-lastInsertId();
//
--
Unfortunately, I get the error, undefined method
DB_mssql::lastInsertId(). What am I doing wrong?
Thanks!
- Bret
View this message in context: undefined method
DB_mssql::lastInsertId() ??
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
--
View this message in context:
http://www.nabble.com/undefined-method-DB_mssql%3A%3AlastInsertId%28%29tf4853199s16154.html#a13888106
Sent from the Zend Framework mailing list archive at Nabble.com.
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
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 [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
--
