phplib-trackers — List for monitoring the phplib SourceForge trackers.

[Phplib-trackers] [ phplib-Patches-450758 ] Support multiple database

[<no...@so...>]

Patches item #450758, was opened at 2001-08-14 21:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450758&group_id=31885

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Richard Archer (richardarcher)
Summary: Support multiple database

Initial Comment:
To support multiple database add 

if (!@mysql_select_db($this->Database,$this->Link_ID)) 
{
  $this->halt("cannot use database ".$this->Database);
}

before each mysql_query() in db_mysql.inc 



----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-04-20 17:30

Message:
Logged In: YES 
user_id=279311

See:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phplib/php-lib/php/db/mysql/db_sql.inc

This change was checked in with v1.9.

This is only in the devel version of PHPLIB at this time.


----------------------------------------------------------------------

Comment By: Ronny Hanssen (godvin)
Date: 2002-04-20 11:34

Message:
Logged In: YES 
user_id=347330

I have tried to find a changelog that tells me that this is 
fixed in any of the versions available without luck. I 
might of course be looking at the wrong places... :)

Is this patch included in any of the packages in the file 
section, or is it in any of the cvs versions (php-lib or 
php-lib-stable)?

How was it implemented? (A diff would be nice...)

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2001-08-27 18:31

Message:
Logged In: YES 
user_id=279311

Done, but not using the method advised :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450758&group_id=31885

[Phplib-trackers] [ phplib-Patches-450758 ] Support multiple database

[<no...@so...>]

Patches item #450758, was opened at 2001-08-14 13:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450758&group_id=31885

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Richard Archer (richardarcher)
Summary: Support multiple database

Initial Comment:
To support multiple database add 

if (!@mysql_select_db($this->Database,$this->Link_ID)) 
{
  $this->halt("cannot use database ".$this->Database);
}

before each mysql_query() in db_mysql.inc 



----------------------------------------------------------------------

Comment By: Ronny Hanssen (godvin)
Date: 2002-04-20 03:34

Message:
Logged In: YES 
user_id=347330

I have tried to find a changelog that tells me that this is 
fixed in any of the versions available without luck. I 
might of course be looking at the wrong places... :)

Is this patch included in any of the packages in the file 
section, or is it in any of the cvs versions (php-lib or 
php-lib-stable)?

How was it implemented? (A diff would be nice...)

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2001-08-27 10:31

Message:
Logged In: YES 
user_id=279311

Done, but not using the method advised :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403613&aid=450758&group_id=31885

[Phplib-trackers] [ phplib-Bugs-545551 ] PHP 4.3.0-DEV incompatibility

[<no...@so...>]

Bugs item #545551, was opened at 2002-04-18 11:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

Category: None
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 9
Submitted By: David S. (dazo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PHP 4.3.0-DEV incompatibility

Initial Comment:
Hello!

I'm running Apache 2.0.35 and PHP-4.3.0-DEV on my
machine and tried to install phplib-7.4pre1

Ok!  Since the latest PHP has some great security
improvements, it's not fully compatible with your
latest phplib.

I noticed these two differences which led to a
modification in php.ini file.

** 1.  allow_call_time_pass_reference (comment taken
out php ini file)
; Whether to enable the ability to force arguments to
be passed by reference
; at function call time.  This method is deprecated and
is likely to be
; unsupported in future versions of PHP/Zend.  The
encouraged method of
; specifying which arguments should be passed by
reference is in the function
; declaration.  You're encouraged to try and turn this
option Off and make
; sure your scripts work properly with it in order to
ensure they will work
; with future versions of the language (you will
receive a warning each time
; you use this feature, and the argument will be passed
by value instead of by
; reference).
allow_call_time_pass_reference = Off

This has to be set to 'On' ... You might want to
consider rewriting this since this option/feature
probably will disapear in the near future ...

** 2.  register_globals (comment from php.ini)
;     Global variables are no longer registered for
input data (POST, GET, cookies,
;     environment and other server variables).  Instead
of using $foo, you must use
;     you can use $_REQUEST["foo"] (includes any
variable that arrives through the
;     request, namely, POST, GET and cookie variables),
or use one of the specific
;     $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or
$_FILES["foo"], depending
;     on where the input originates.  Also, you can
look at the
;     import_request_variables() function.
;     Note that register_globals is going to be
depracated (i.e., turned off by
;     default) in the next version of PHP, because it
often leads to security bugs.
;     Read
http://php.net/manual/en/security.registerglobals.php
for further
;     information.
register_globals = Off

This also has to be set to 'On'  ... this feature I
simply decline to set to On due to security risks.  And
this feature/option will also disapear in the near
future ...

I also noticed that a line is missing in the
db_pgsql.inc ...  Add
	var $Port     = "";
in the DB_Sql class.

And one last thing ... since PHP4 ... all the
extensions on this PHP scripts are .php ... so you
might want to rename all the files ... if not, the user
have to edit the Apache configuration file (httpd.conf)
to enable .php3 files to act as .php files.  

If it wasn't for all this, I would have started using
the library today, but I don't dare to do that now
because I must rely on features in the latest PHP
version and since the most important PHP options might
disapear I can not bind myself to this library.

Except for this, this library seems to be great!

----------------------------------------------------------------------

>Comment By: David S. (dazo)
Date: 2002-04-19 11:16

Message:
Logged In: YES 
user_id=231324

I took the latest CVS version and tried it!  Much better!

But I do get a strange error/notice from PHP:

Notice: Undefined index: error in phplib/auth/sql/auth.inc
on line 194

I tried to add the an error variable (var $error = "") in
both the phplib/auth/auth.inc and phplib/auth/sql/auth.inc

But it didn't seem to work ... I'm gonna have a close look
on this one. (In my php.ini I have: error_reporting  = 
E_ALL; display_errors = On; display_startup_errors = On; 
--- and thats the reason it screams about it, but I'm
paranoid so I like to see my mistakes! ;-)

Keep up the good work!  This is great!


David S.
I also added a patch for the pgsql driver (the $Port
variable)

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-18 18:01

Message:
Logged In: YES 
user_id=278685

1. allow_call_time_pass_reference
This was fixed in session.inc last August so it should be 
fixed in 7.4pre1 - user.inc has since been fixed in CVS 
(fix yours by removing the ampersand in the calls to $this-
>serialize()) and there is one roque occurrence in 
layout_html.inc (on its way to being fixed) and one use in 
db_odbc.inc's next_record().

2. register_globals
This also is fixed in CVS. 

3. db_pgsql.inc
If you will provide a patch for using that parameter, we 
can get it into CVS.

4. file extensions
This has been asked before - I hate to keep .php3, but I 
also hate sending files to the CVS Attic just to change 
their name - it disconnects their history. I'll let someone 
else do the deed.

Unfortunately, I think there's still a bit of work to do 
before the next release. I have tested the latest CVS and 
it is now on my production servers - I recommend checking 
it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-545551 ] PHP 4.3.0-DEV incompatibility

[<no...@so...>]

Bugs item #545551, was opened at 2002-04-18 04:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

Category: None
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 9
Submitted By: David S. (dazo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PHP 4.3.0-DEV incompatibility

Initial Comment:
Hello!

I'm running Apache 2.0.35 and PHP-4.3.0-DEV on my
machine and tried to install phplib-7.4pre1

Ok!  Since the latest PHP has some great security
improvements, it's not fully compatible with your
latest phplib.

I noticed these two differences which led to a
modification in php.ini file.

** 1.  allow_call_time_pass_reference (comment taken
out php ini file)
; Whether to enable the ability to force arguments to
be passed by reference
; at function call time.  This method is deprecated and
is likely to be
; unsupported in future versions of PHP/Zend.  The
encouraged method of
; specifying which arguments should be passed by
reference is in the function
; declaration.  You're encouraged to try and turn this
option Off and make
; sure your scripts work properly with it in order to
ensure they will work
; with future versions of the language (you will
receive a warning each time
; you use this feature, and the argument will be passed
by value instead of by
; reference).
allow_call_time_pass_reference = Off

This has to be set to 'On' ... You might want to
consider rewriting this since this option/feature
probably will disapear in the near future ...

** 2.  register_globals (comment from php.ini)
;     Global variables are no longer registered for
input data (POST, GET, cookies,
;     environment and other server variables).  Instead
of using $foo, you must use
;     you can use $_REQUEST["foo"] (includes any
variable that arrives through the
;     request, namely, POST, GET and cookie variables),
or use one of the specific
;     $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or
$_FILES["foo"], depending
;     on where the input originates.  Also, you can
look at the
;     import_request_variables() function.
;     Note that register_globals is going to be
depracated (i.e., turned off by
;     default) in the next version of PHP, because it
often leads to security bugs.
;     Read
http://php.net/manual/en/security.registerglobals.php
for further
;     information.
register_globals = Off

This also has to be set to 'On'  ... this feature I
simply decline to set to On due to security risks.  And
this feature/option will also disapear in the near
future ...

I also noticed that a line is missing in the
db_pgsql.inc ...  Add
	var $Port     = "";
in the DB_Sql class.

And one last thing ... since PHP4 ... all the
extensions on this PHP scripts are .php ... so you
might want to rename all the files ... if not, the user
have to edit the Apache configuration file (httpd.conf)
to enable .php3 files to act as .php files.  

If it wasn't for all this, I would have started using
the library today, but I don't dare to do that now
because I must rely on features in the latest PHP
version and since the most important PHP options might
disapear I can not bind myself to this library.

Except for this, this library seems to be great!

----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-18 11:01

Message:
Logged In: YES 
user_id=278685

1. allow_call_time_pass_reference
This was fixed in session.inc last August so it should be 
fixed in 7.4pre1 - user.inc has since been fixed in CVS 
(fix yours by removing the ampersand in the calls to $this-
>serialize()) and there is one roque occurrence in 
layout_html.inc (on its way to being fixed) and one use in 
db_odbc.inc's next_record().

2. register_globals
This also is fixed in CVS. 

3. db_pgsql.inc
If you will provide a patch for using that parameter, we 
can get it into CVS.

4. file extensions
This has been asked before - I hate to keep .php3, but I 
also hate sending files to the CVS Attic just to change 
their name - it disconnects their history. I'll let someone 
else do the deed.

Unfortunately, I think there's still a bit of work to do 
before the next release. I have tested the latest CVS and 
it is now on my production servers - I recommend checking 
it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-545551 ] PHP 4.3.0-DEV incompatibility

[<no...@so...>]

Bugs item #545551, was opened at 2002-04-18 11:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

Category: None
Group: 7.4pre1
Status: Open
Resolution: None
>Priority: 9
Submitted By: David S. (dazo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PHP 4.3.0-DEV incompatibility

Initial Comment:
Hello!

I'm running Apache 2.0.35 and PHP-4.3.0-DEV on my
machine and tried to install phplib-7.4pre1

Ok!  Since the latest PHP has some great security
improvements, it's not fully compatible with your
latest phplib.

I noticed these two differences which led to a
modification in php.ini file.

** 1.  allow_call_time_pass_reference (comment taken
out php ini file)
; Whether to enable the ability to force arguments to
be passed by reference
; at function call time.  This method is deprecated and
is likely to be
; unsupported in future versions of PHP/Zend.  The
encouraged method of
; specifying which arguments should be passed by
reference is in the function
; declaration.  You're encouraged to try and turn this
option Off and make
; sure your scripts work properly with it in order to
ensure they will work
; with future versions of the language (you will
receive a warning each time
; you use this feature, and the argument will be passed
by value instead of by
; reference).
allow_call_time_pass_reference = Off

This has to be set to 'On' ... You might want to
consider rewriting this since this option/feature
probably will disapear in the near future ...

** 2.  register_globals (comment from php.ini)
;     Global variables are no longer registered for
input data (POST, GET, cookies,
;     environment and other server variables).  Instead
of using $foo, you must use
;     you can use $_REQUEST["foo"] (includes any
variable that arrives through the
;     request, namely, POST, GET and cookie variables),
or use one of the specific
;     $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or
$_FILES["foo"], depending
;     on where the input originates.  Also, you can
look at the
;     import_request_variables() function.
;     Note that register_globals is going to be
depracated (i.e., turned off by
;     default) in the next version of PHP, because it
often leads to security bugs.
;     Read
http://php.net/manual/en/security.registerglobals.php
for further
;     information.
register_globals = Off

This also has to be set to 'On'  ... this feature I
simply decline to set to On due to security risks.  And
this feature/option will also disapear in the near
future ...

I also noticed that a line is missing in the
db_pgsql.inc ...  Add
	var $Port     = "";
in the DB_Sql class.

And one last thing ... since PHP4 ... all the
extensions on this PHP scripts are .php ... so you
might want to rename all the files ... if not, the user
have to edit the Apache configuration file (httpd.conf)
to enable .php3 files to act as .php files.  

If it wasn't for all this, I would have started using
the library today, but I don't dare to do that now
because I must rely on features in the latest PHP
version and since the most important PHP options might
disapear I can not bind myself to this library.

Except for this, this library seems to be great!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-545551 ] PHP 4.3.0-DEV incompatibility

[<no...@so...>]

Bugs item #545551, was opened at 2002-04-18 11:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

Category: None
Group: 7.4pre1
Status: Open
Resolution: None
Priority: 5
Submitted By: David S. (dazo)
Assigned to: Nobody/Anonymous (nobody)
Summary: PHP 4.3.0-DEV incompatibility

Initial Comment:
Hello!

I'm running Apache 2.0.35 and PHP-4.3.0-DEV on my
machine and tried to install phplib-7.4pre1

Ok!  Since the latest PHP has some great security
improvements, it's not fully compatible with your
latest phplib.

I noticed these two differences which led to a
modification in php.ini file.

** 1.  allow_call_time_pass_reference (comment taken
out php ini file)
; Whether to enable the ability to force arguments to
be passed by reference
; at function call time.  This method is deprecated and
is likely to be
; unsupported in future versions of PHP/Zend.  The
encouraged method of
; specifying which arguments should be passed by
reference is in the function
; declaration.  You're encouraged to try and turn this
option Off and make
; sure your scripts work properly with it in order to
ensure they will work
; with future versions of the language (you will
receive a warning each time
; you use this feature, and the argument will be passed
by value instead of by
; reference).
allow_call_time_pass_reference = Off

This has to be set to 'On' ... You might want to
consider rewriting this since this option/feature
probably will disapear in the near future ...

** 2.  register_globals (comment from php.ini)
;     Global variables are no longer registered for
input data (POST, GET, cookies,
;     environment and other server variables).  Instead
of using $foo, you must use
;     you can use $_REQUEST["foo"] (includes any
variable that arrives through the
;     request, namely, POST, GET and cookie variables),
or use one of the specific
;     $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or
$_FILES["foo"], depending
;     on where the input originates.  Also, you can
look at the
;     import_request_variables() function.
;     Note that register_globals is going to be
depracated (i.e., turned off by
;     default) in the next version of PHP, because it
often leads to security bugs.
;     Read
http://php.net/manual/en/security.registerglobals.php
for further
;     information.
register_globals = Off

This also has to be set to 'On'  ... this feature I
simply decline to set to On due to security risks.  And
this feature/option will also disapear in the near
future ...

I also noticed that a line is missing in the
db_pgsql.inc ...  Add
	var $Port     = "";
in the DB_Sql class.

And one last thing ... since PHP4 ... all the
extensions on this PHP scripts are .php ... so you
might want to rename all the files ... if not, the user
have to edit the Apache configuration file (httpd.conf)
to enable .php3 files to act as .php files.  

If it wasn't for all this, I would have started using
the library today, but I don't dare to do that now
because I must rely on features in the latest PHP
version and since the most important PHP options might
disapear I can not bind myself to this library.

Except for this, this library seems to be great!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=545551&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-543468 ] unset_vat for template.inc!

[<no...@so...>]

Feature Requests item #543468, was opened at 2002-04-13 14:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

Category: None
Group: None
Status: Open
>Priority: 1
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: unset_vat for template.inc!

Initial Comment:
Please add a method unset_var("varname/array") to the template engine.
This is required when handling blocks within blocks!!!!
Because in this situation you have sometime to clear already set variables!
Blocks within blocks can be very power- and helpfull but one ran into strange situations when no 
unset_var is available.
Its 5 Minutes of work or less!

Thanks.


----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-15 10:13

Message:
Logged In: YES 
user_id=278685

A unset_var() (or clear_var() as I use in my personal 
extension) is simply an alias for set_var("varname", ""). 
Someone may get around to adding such an alias to the 
official library, but it is far less urgent than many 
existing bugs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-543468 ] unset_vat for template.inc!

[<no...@so...>]

Feature Requests item #543468, was opened at 2002-04-13 21:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Dipl.-Inform. Kai Hofmann (powerstat)
Assigned to: Nobody/Anonymous (nobody)
Summary: unset_vat for template.inc!

Initial Comment:
Please add a method unset_var("varname/array") to the template engine.
This is required when handling blocks within blocks!!!!
Because in this situation you have sometime to clear already set variables!
Blocks within blocks can be very power- and helpfull but one ran into strange situations when no 
unset_var is available.
Its 5 Minutes of work or less!

Thanks.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403614&aid=543468&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542811 ] nextid() uses mysql_query

[<no...@so...>]

Bugs item #542811, was opened at 2002-04-11 22:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542811&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 2
Submitted By: Layne Weathers (layne_weathers)
Assigned to: Layne Weathers (layne_weathers)
Summary: nextid() uses mysql_query

Initial Comment:
nextid() uses mysql_query() and mysql_fetch_array() 
instead of using DB_Sql's own error-checking functions.

----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-12 10:40

Message:
Logged In: YES 
user_id=278685

I guess this is in the case of duplicating or moving data 
from one table to another. In that case, I would need to 
have two database objects - one to query the old table and 
the second to insert into the new table (if I tried to use 
only one object I would lose my select results) so I might 
as well nextid() with the second object.

I guess I could save all the data in an array, but then I 
don't see any reason not to get the id later when I'm 
looping through the array.

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-04-12 00:23

Message:
Logged In: YES 
user_id=279311

It does this so as to not trash the $this->Record array. The
script could conceivably be looping through this array and
using next_id() for each element!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542811&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542811 ] nextid() uses mysql_query

[<no...@so...>]

Bugs item #542811, was opened at 2002-04-12 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542811&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 2
Submitted By: Layne Weathers (layne_weathers)
Assigned to: Layne Weathers (layne_weathers)
Summary: nextid() uses mysql_query

Initial Comment:
nextid() uses mysql_query() and mysql_fetch_array() 
instead of using DB_Sql's own error-checking functions.

----------------------------------------------------------------------

>Comment By: Richard Archer (richardarcher)
Date: 2002-04-12 15:23

Message:
Logged In: YES 
user_id=279311

It does this so as to not trash the $this->Record array. The
script could conceivably be looping through this array and
using next_id() for each element!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542811&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542811 ] nextid() uses mysql_query

[<no...@so...>]

Bugs item #542811, was opened at 2002-04-11 22:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542811&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 2
Submitted By: Layne Weathers (layne_weathers)
Assigned to: Layne Weathers (layne_weathers)
Summary: nextid() uses mysql_query

Initial Comment:
nextid() uses mysql_query() and mysql_fetch_array() 
instead of using DB_Sql's own error-checking functions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542811&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542808 ] nextid()'s lock() in db_mysql.inc

[<no...@so...>]

Bugs item #542808, was opened at 2002-04-11 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542808&group_id=31885

Category: DB_SQL
Group: current CVS
Status: Open
Resolution: None
Priority: 5
Submitted By: Layne Weathers (layne_weathers)
Assigned to: Nobody/Anonymous (nobody)
Summary: nextid()'s lock() in db_mysql.inc

Initial Comment:
nextid() issues a table lock on the db_sequence table -
 this will release any previous locks. I do not 
believe that nextid() is competent to make that 
decision on its own. In most applications, I lock 
tables before modifying any data, do integrity and 
validity tests on the new data, and finally make the 
changes. Since I don't like throwing away auto-
incrementing ID #s, I don't call nextid() until right 
before the insert statement. Unfortunately, nextid() 
will release my other locks and compromise my efforts 
at data integrity.

If my methodology above is flawed I am willing to 
change it, but until persuaded otherwise I propose the 
following order for nextid(): 

1. check to see if an instance-level lock is in place
  1.1. if not, try to put a lock on the sequence table
      1.1.1. if successful, record that a local lock 
was used
      1.1.2. if unsuccessful, fail with current warning

2. get current id, increment it, write it to table 
(unmodified)

3. check for a local lock
  3.1 if so, release it


(Yes, this will cause problems in existing code where 
nextid() is used within a set of locked tables and the 
sequence table was not locked - the author was sloppy 
and overlooked the sequence table, s/he should fix the 
code.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542808&group_id=31885

[Phplib-trackers] [ phplib-Bugs-532869 ] Demo privileges broken

[<no...@so...>]

Bugs item #532869, was opened at 2002-03-21 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=532869&group_id=31885

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Richard Archer (richardarcher)
Summary: Demo privileges broken

Initial Comment:
The privilege settings in the demonstration on your 
website seem broken:

 - when the non-admin user looks at the userlevel, 
they frequently see "Array" rather than anything 
useful.

 - when the admin user looks at it, the select-box 
contains nothing selected, and usually submitting it 
(even after selecting one) shows an error.

----------------------------------------------------------------------

Comment By: Gavin Lambert (uecasm)
Date: 2002-04-12 10:08

Message:
Logged In: YES 
user_id=208929

Perhaps you'd better update the website demo to use that 
version, then, because it's still broken.

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-12 04:19

Message:
Logged In: YES 
user_id=278685

This was fixed in the 7.4pre1 release.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=532869&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542612 ] backslashes lost by subst()

[<no...@so...>]

Bugs item #542612, was opened at 2002-04-11 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542612&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott Lahteine (slurslee)
Assigned to: Nobody/Anonymous (nobody)
Summary: backslashes lost by subst()

Initial Comment:
The subst() function in template.inc uses 
preg_replace to merge variables with page 
content. The trouble with preg_replace is that its 
second argument, the replacement string, is 
treated in a "grep-like" way, such that the 
backslash character has a special meaning. So 
every backslash needs to be doubled before doing 
the replacement, or else every other one will be 
stripped out.

To fix the preg_replace problem I changed the 
subst() function like so:

 function subst($handle) {
   if (!$this->loadfile($handle)) {
     $this->halt("subst: unable to load $handle.");
     return false;
   }
 
   $str = $this->get_var($handle);
 
   // THESE LINES WERE ADDED BY ME
   foreach ($this->varvals as $k=>$v)
       $this->varvalsfixed[$k] = preg_replace('/\/', '\\', 
$v);
 
   // AND I CHANGED THIS LINE TOO
   $str = @preg_replace($this->varkeys, $this->
varvalsfixed, $str);
 
   return $str;
 }


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542612&group_id=31885

[Phplib-trackers] [ phplib-Feature Requests-526615 ] Template addition

[<no...@so...>]

Feature Requests item #526615, was opened at 2002-03-06 14:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403614&aid=526615&group_id=31885

Category: None
Group: None
>Status: Deleted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Template addition

Initial Comment:
I would like a conditional flag for the set_file 
fuction that cleans all <html> to <body> tags and all 
</body to </html> tags.

This would allow our designs to work in a regular html 
file with back grounds and standard CSS etc. while not 
duplicating the head info when parced. 

----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-11 11:30

Message:
Logged In: YES 
user_id=278685

The consensus among the PHPLib leadership has always been 
that logical elements should not be included in Template.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-07 19:46

Message:
Logged In: NO 

Thank you, we use methods like that but we still rely on 
the designers etc. to do this consistently and constantly.

Just would be nice to be able to clean with one boolean 
flag per file assignment instead.

Looking at the comment I made, it makes more sence to clear 
everything from the begining of the file to the first 
occurence of '>' after '<body'.

----------------------------------------------------------------------

Comment By: Richard Archer (richardarcher)
Date: 2002-03-07 14:41

Message:
Logged In: YES 
user_id=279311

try something like:
<!-- START HEAD --><html>...<body><!-- END HEAD -->
<p>all your html here</p>
<!-- START FOOT --></body></html><!-- END FOOT -->

$t->set_block("the_page", "HEAD", head");
$t->set_block("the_page", "FOOT", "foot");
$t->set_var(array("head" => "", "foot" => ""));

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403614&aid=526615&group_id=31885

[Phplib-trackers] [ phplib-Bugs-532869 ] Demo privileges broken

[<no...@so...>]

Bugs item #532869, was opened at 2002-03-20 20:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=532869&group_id=31885

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Richard Archer (richardarcher)
Summary: Demo privileges broken

Initial Comment:
The privilege settings in the demonstration on your 
website seem broken:

 - when the non-admin user looks at the userlevel, 
they frequently see "Array" rather than anything 
useful.

 - when the admin user looks at it, the select-box 
contains nothing selected, and usually submitting it 
(even after selecting one) shows an error.

----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-11 11:19

Message:
Logged In: YES 
user_id=278685

This was fixed in the 7.4pre1 release.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=532869&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542517 ] Session.inc warnings

[<no...@so...>]

Bugs item #542517, was opened at 2002-04-11 09:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542517&group_id=31885

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Richard Archer (richardarcher)
Summary: Session.inc warnings

Initial Comment:
On PHP 4.1.2 the following warning occur (5 times) in 
session.inc

Warning: Call-time pass-by-reference has been 
deprecated - argument passed
by value; If you would like to pass it by reference, 
modify the declaration
of [runtime function name](). If you would like to 
enable call-time
pass-by-reference, you can set 
allow_call_time_pass_reference to true in
your INI file. However, future versions may not 
support this any longer. in
/home/sites/site200/web/include/session.inc on line 310

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542517&group_id=31885

[Phplib-trackers] [ phplib-Bugs-541551 ] db_mysql lock tables

[<no...@so...>]

Bugs item #541551, was opened at 2002-04-09 09:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

Category: None
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: NickM (terado)
Assigned to: Layne Weathers (layne_weathers)
Summary: db_mysql lock tables

Initial Comment:
When issuing a lock command with an array of values, 
e.g.:
$db->lock(array("table1"=>"read", "table2"=>"read"));

this is resolved wrongly in the lock function, and 
instead attempts:

lock tables read table1, read table2

now if the array is created the other way the 
obviously "read" would be the index and be 
overwritten!!

Resolve:
$key/$value other way around:-

      while (list($key,$value) = each($table)) {
        if (!is_int($key)) {
		  // lock modes are "read", "read 
local", "write", "low priority write"
          $query .= "$key $value, ";
        } else {
          $query .= "$key $mode, ";
        }
      }





----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 16:04

Message:
Logged In: YES 
user_id=501841

ei bogus, I did a half cut copy and paste from cvs, only 
half the lock function.  You can slap me gently lol.

btw thought group (being it says v1.0) was for classes of 
release, thats the only reason I mentioned it.

Ta

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 15:24

Message:
Logged In: YES 
user_id=278685

> I find this extremely confusing, and unclear. 
> Especially the fact that one way goes from
> table list to mode and the other from mode
> to table list, but I can adjust to the logic :)
> If not a bug in code this certainly is a docs 
> bug, the examples would do well in with the
> description at least.

I agree that it is a confusing way for the function to 
function. Unfortunately, it was previously written that way 
and we don't want to break old code if we can help it, 
expecially in a point release.

> Secondly - the following method does not work:
> $db->lock("dj, dj2music_cats as dj2mc,
> music_cats as mc", "read");
> 
> Now this can be achieved using the array method,
> but both ought to work.

It does work in the current CVS version. I just ran this 
array of tests to make sure: (I temporarily modified lock() 
to echo "<p>$query"; so I could see the results)
$db->lock("auth_user_md5 as a_u", "read");
$db->lock("auth_user as a_u, active_sessions a_s, 
db_sequence", "read");
$db->lock(array("read" => "auth_user as a_u"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s", "write" => "db_sequence"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s", "write" => "db_sequence seq"));


> Thirdly (side thing) the changes were in the
> CVS, I was using the release version.  Cant
> the bug logging form allow identification of
> which version the bug is being logged 
> against.

That would have to be taken up with SourceForge.

----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 14:27

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list.  If not a bug in code this 
certainly is a docs bug, the examples would do well in with 
the description at least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 11:19

Message:
Logged In: YES 
user_id=278685

> When issuing a lock command with an array of values, 
> e.g.:
> $db->lock(array("table1"=>"read", "table2"=>"read"));
> 
> this is resolved wrongly in the lock function, and 
> instead attempts:
> 
> lock tables read table1, read table2

That has never been the correct way to call lock(), even 
before the recent changes to lock(). The online 
documentation at 
<http://www.sanisoft.com/phplib/manual/DB_SqlMethods.php> 
was vague, so I added some examples.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-542517 ] Session.inc warnings

[<no...@so...>]

Bugs item #542517, was opened at 2002-04-11 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542517&group_id=31885

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Session.inc warnings

Initial Comment:
On PHP 4.1.2 the following warning occur (5 times) in 
session.inc

Warning: Call-time pass-by-reference has been 
deprecated - argument passed
by value; If you would like to pass it by reference, 
modify the declaration
of [runtime function name](). If you would like to 
enable call-time
pass-by-reference, you can set 
allow_call_time_pass_reference to true in
your INI file. However, future versions may not 
support this any longer. in
/home/sites/site200/web/include/session.inc on line 310

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=542517&group_id=31885

[Phplib-trackers] [ phplib-Bugs-541551 ] db_mysql lock tables

[<no...@so...>]

Bugs item #541551, was opened at 2002-04-09 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

Category: None
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: NickM (terado)
Assigned to: Layne Weathers (layne_weathers)
Summary: db_mysql lock tables

Initial Comment:
When issuing a lock command with an array of values, 
e.g.:
$db->lock(array("table1"=>"read", "table2"=>"read"));

this is resolved wrongly in the lock function, and 
instead attempts:

lock tables read table1, read table2

now if the array is created the other way the 
obviously "read" would be the index and be 
overwritten!!

Resolve:
$key/$value other way around:-

      while (list($key,$value) = each($table)) {
        if (!is_int($key)) {
		  // lock modes are "read", "read 
local", "write", "low priority write"
          $query .= "$key $value, ";
        } else {
          $query .= "$key $mode, ";
        }
      }





----------------------------------------------------------------------

>Comment By: NickM (terado)
Date: 2002-04-09 21:04

Message:
Logged In: YES 
user_id=501841

ei bogus, I did a half cut copy and paste from cvs, only 
half the lock function.  You can slap me gently lol.

btw thought group (being it says v1.0) was for classes of 
release, thats the only reason I mentioned it.

Ta

----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 20:24

Message:
Logged In: YES 
user_id=278685

> I find this extremely confusing, and unclear. 
> Especially the fact that one way goes from
> table list to mode and the other from mode
> to table list, but I can adjust to the logic :)
> If not a bug in code this certainly is a docs 
> bug, the examples would do well in with the
> description at least.

I agree that it is a confusing way for the function to 
function. Unfortunately, it was previously written that way 
and we don't want to break old code if we can help it, 
expecially in a point release.

> Secondly - the following method does not work:
> $db->lock("dj, dj2music_cats as dj2mc,
> music_cats as mc", "read");
> 
> Now this can be achieved using the array method,
> but both ought to work.

It does work in the current CVS version. I just ran this 
array of tests to make sure: (I temporarily modified lock() 
to echo "<p>$query"; so I could see the results)
$db->lock("auth_user_md5 as a_u", "read");
$db->lock("auth_user as a_u, active_sessions a_s, 
db_sequence", "read");
$db->lock(array("read" => "auth_user as a_u"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s", "write" => "db_sequence"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s", "write" => "db_sequence seq"));


> Thirdly (side thing) the changes were in the
> CVS, I was using the release version.  Cant
> the bug logging form allow identification of
> which version the bug is being logged 
> against.

That would have to be taken up with SourceForge.

----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 19:27

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list.  If not a bug in code this 
certainly is a docs bug, the examples would do well in with 
the description at least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 16:19

Message:
Logged In: YES 
user_id=278685

> When issuing a lock command with an array of values, 
> e.g.:
> $db->lock(array("table1"=>"read", "table2"=>"read"));
> 
> this is resolved wrongly in the lock function, and 
> instead attempts:
> 
> lock tables read table1, read table2

That has never been the correct way to call lock(), even 
before the recent changes to lock(). The online 
documentation at 
<http://www.sanisoft.com/phplib/manual/DB_SqlMethods.php> 
was vague, so I added some examples.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-541551 ] db_mysql lock tables

[<no...@so...>]

Bugs item #541551, was opened at 2002-04-09 09:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

Category: None
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: NickM (terado)
Assigned to: Layne Weathers (layne_weathers)
Summary: db_mysql lock tables

Initial Comment:
When issuing a lock command with an array of values, 
e.g.:
$db->lock(array("table1"=>"read", "table2"=>"read"));

this is resolved wrongly in the lock function, and 
instead attempts:

lock tables read table1, read table2

now if the array is created the other way the 
obviously "read" would be the index and be 
overwritten!!

Resolve:
$key/$value other way around:-

      while (list($key,$value) = each($table)) {
        if (!is_int($key)) {
		  // lock modes are "read", "read 
local", "write", "low priority write"
          $query .= "$key $value, ";
        } else {
          $query .= "$key $mode, ";
        }
      }





----------------------------------------------------------------------

>Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 15:24

Message:
Logged In: YES 
user_id=278685

> I find this extremely confusing, and unclear. 
> Especially the fact that one way goes from
> table list to mode and the other from mode
> to table list, but I can adjust to the logic :)
> If not a bug in code this certainly is a docs 
> bug, the examples would do well in with the
> description at least.

I agree that it is a confusing way for the function to 
function. Unfortunately, it was previously written that way 
and we don't want to break old code if we can help it, 
expecially in a point release.

> Secondly - the following method does not work:
> $db->lock("dj, dj2music_cats as dj2mc,
> music_cats as mc", "read");
> 
> Now this can be achieved using the array method,
> but both ought to work.

It does work in the current CVS version. I just ran this 
array of tests to make sure: (I temporarily modified lock() 
to echo "<p>$query"; so I could see the results)
$db->lock("auth_user_md5 as a_u", "read");
$db->lock("auth_user as a_u, active_sessions a_s, 
db_sequence", "read");
$db->lock(array("read" => "auth_user as a_u"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s", "write" => "db_sequence"));
$db->lock(array("read" => "auth_user as a_u, 
active_sessions a_s", "write" => "db_sequence seq"));


> Thirdly (side thing) the changes were in the
> CVS, I was using the release version.  Cant
> the bug logging form allow identification of
> which version the bug is being logged 
> against.

That would have to be taken up with SourceForge.

----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 14:27

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list.  If not a bug in code this 
certainly is a docs bug, the examples would do well in with 
the description at least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 11:19

Message:
Logged In: YES 
user_id=278685

> When issuing a lock command with an array of values, 
> e.g.:
> $db->lock(array("table1"=>"read", "table2"=>"read"));
> 
> this is resolved wrongly in the lock function, and 
> instead attempts:
> 
> lock tables read table1, read table2

That has never been the correct way to call lock(), even 
before the recent changes to lock(). The online 
documentation at 
<http://www.sanisoft.com/phplib/manual/DB_SqlMethods.php> 
was vague, so I added some examples.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-541551 ] db_mysql lock tables

[<no...@so...>]

Bugs item #541551, was opened at 2002-04-09 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

Category: None
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: NickM (terado)
>Assigned to: Layne Weathers (layne_weathers)
Summary: db_mysql lock tables

Initial Comment:
When issuing a lock command with an array of values, 
e.g.:
$db->lock(array("table1"=>"read", "table2"=>"read"));

this is resolved wrongly in the lock function, and 
instead attempts:

lock tables read table1, read table2

now if the array is created the other way the 
obviously "read" would be the index and be 
overwritten!!

Resolve:
$key/$value other way around:-

      while (list($key,$value) = each($table)) {
        if (!is_int($key)) {
		  // lock modes are "read", "read 
local", "write", "low priority write"
          $query .= "$key $value, ";
        } else {
          $query .= "$key $mode, ";
        }
      }





----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 19:27

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list.  If not a bug in code this 
certainly is a docs bug, the examples would do well in with 
the description at least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 16:19

Message:
Logged In: YES 
user_id=278685

> When issuing a lock command with an array of values, 
> e.g.:
> $db->lock(array("table1"=>"read", "table2"=>"read"));
> 
> this is resolved wrongly in the lock function, and 
> instead attempts:
> 
> lock tables read table1, read table2

That has never been the correct way to call lock(), even 
before the recent changes to lock(). The online 
documentation at 
<http://www.sanisoft.com/phplib/manual/DB_SqlMethods.php> 
was vague, so I added some examples.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-541551 ] db_mysql lock tables

[<no...@so...>]

Bugs item #541551, was opened at 2002-04-09 14:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: NickM (terado)
Assigned to: Nobody/Anonymous (nobody)
Summary: db_mysql lock tables

Initial Comment:
When issuing a lock command with an array of values, 
e.g.:
$db->lock(array("table1"=>"read", "table2"=>"read"));

this is resolved wrongly in the lock function, and 
instead attempts:

lock tables read table1, read table2

now if the array is created the other way the 
obviously "read" would be the index and be 
overwritten!!

Resolve:
$key/$value other way around:-

      while (list($key,$value) = each($table)) {
        if (!is_int($key)) {
		  // lock modes are "read", "read 
local", "write", "low priority write"
          $query .= "$key $value, ";
        } else {
          $query .= "$key $mode, ";
        }
      }





----------------------------------------------------------------------

>Comment By: NickM (terado)
Date: 2002-04-09 19:27

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list.  If not a bug in code this 
certainly is a docs bug, the examples would do well in with 
the description at least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2002-04-09 16:19

Message:
Logged In: YES 
user_id=278685

> When issuing a lock command with an array of values, 
> e.g.:
> $db->lock(array("table1"=>"read", "table2"=>"read"));
> 
> this is resolved wrongly in the lock function, and 
> instead attempts:
> 
> lock tables read table1, read table2

That has never been the correct way to call lock(), even 
before the recent changes to lock(). The online 
documentation at 
<http://www.sanisoft.com/phplib/manual/DB_SqlMethods.php> 
was vague, so I added some examples.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=541551&group_id=31885

[Phplib-trackers] [ phplib-Bugs-470493 ] bug in db_mysql.inc function lock (?)

[<no...@so...>]

Bugs item #470493, was opened at 2001-10-12 07:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=470493&group_id=31885

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Layne Weathers (layne_weathers)
Summary: bug in db_mysql.inc function lock (?)

Initial Comment:
Hello,

Line 174 of the file db_mysql.inc (v. phplib-7.2d)

   if ($key=="read" && $key!=0)

This test looks strange.
$key!=0 will only be evaluated when $key=="read" so
the next test $key!=0 is not usefull as we already
knows that $key is "read" when we enter the second part
of the test.
As you put the mode "write" or "read" in the variable
$mode I presume it's a typo error and the test
should be if ($mode=="read"...)

  /* public: table locking */
  function lock($table, $mode="write") {
    $this->connect();
         
    $query="lock tables ";
    if (is_array($table)) {
      while (list($key,$value)=each($table)) {
        if ($key=="read" && $key!=0) { <======= HERE                               $query.="$value read, ";
        } else {
          $query.="$value $mode, ";
        }
      }
      $query=substr($query,0,-2);

Kind regards,

Olivier Boudry

----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 19:24

Message:
Logged In: YES 
user_id=501841

oops, ignore that - meant to go in other locking bug :">  
sorry

----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 19:20

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list, but I can adjust to the 
logic :)  If not a bug in code this certainly is a docs 
bug, the examples would do well in with the description at 
least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2001-10-12 16:10

Message:
Logged In: YES 
user_id=278685

In addition to this issue, I am disturbed by 1) lock() only 
allowing 'read' and 'write' as locking modes and 2) neither 
lock() nor unlock() use the query().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=470493&group_id=31885

[Phplib-trackers] [ phplib-Bugs-470493 ] bug in db_mysql.inc function lock (?)

[<no...@so...>]

Bugs item #470493, was opened at 2001-10-12 07:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=470493&group_id=31885

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Layne Weathers (layne_weathers)
Summary: bug in db_mysql.inc function lock (?)

Initial Comment:
Hello,

Line 174 of the file db_mysql.inc (v. phplib-7.2d)

   if ($key=="read" && $key!=0)

This test looks strange.
$key!=0 will only be evaluated when $key=="read" so
the next test $key!=0 is not usefull as we already
knows that $key is "read" when we enter the second part
of the test.
As you put the mode "write" or "read" in the variable
$mode I presume it's a typo error and the test
should be if ($mode=="read"...)

  /* public: table locking */
  function lock($table, $mode="write") {
    $this->connect();
         
    $query="lock tables ";
    if (is_array($table)) {
      while (list($key,$value)=each($table)) {
        if ($key=="read" && $key!=0) { <======= HERE                               $query.="$value read, ";
        } else {
          $query.="$value $mode, ";
        }
      }
      $query=substr($query,0,-2);

Kind regards,

Olivier Boudry

----------------------------------------------------------------------

Comment By: NickM (terado)
Date: 2002-04-09 19:20

Message:
Logged In: YES 
user_id=501841

I find this extremely confusing, and unclear.  Especially 
the fact that one way goes from table list to mode and the 
other from mode to table list, but I can adjust to the 
logic :)  If not a bug in code this certainly is a docs 
bug, the examples would do well in with the description at 
least.

Secondly - the following method does not work:
$db->lock("dj, dj2music_cats as dj2mc, music_cats as 
mc", "read");

Now this can be achieved using the array method, but both 
ought to work.

Thirdly (side thing) the changes were in the CVS, I was 
using the release version.  Cant the bug logging form allow 
identification of which version the bug is being logged 
against.



----------------------------------------------------------------------

Comment By: Layne Weathers (layne_weathers)
Date: 2001-10-12 16:10

Message:
Logged In: YES 
user_id=278685

In addition to this issue, I am disturbed by 1) lock() only 
allowing 'read' and 'write' as locking modes and 2) neither 
lock() nor unlock() use the query().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=403611&aid=470493&group_id=31885