php-general Digest 20 Mar 2010 10:35:42 -0000 Issue 6649
Topics (messages 303021 through 303041):
Re: any reason *not* to use PEAR DB module when accessing mysql?
303021 by: Michael A. Peters
303032 by: Nilesh Govindarajan
303034 by: Michael A. Peters
303035 by: Nilesh Govindarajan
303039 by: Paul M Foster
php compile / configure options
303022 by: Gregory Machin
303033 by: Nilesh Govindarajan
303036 by: Simon J Welsh
Re: Spreadsheet_Excel_Reader problem
303023 by: Jason Pruim
303024 by: Ashley Sheridan
303026 by: Andrew Ballard
303027 by: Andrew Ballard
303037 by: Paul M Foster
303038 by: Paul M Foster
Re: where to make observations about current PHP manual?
303025 by: Shawn McKenzie
303028 by: Robert P. J. Day
303029 by: Daniel Brown
303030 by: Daniel Brown
303031 by: Daniel Brown
303040 by: Robert P. J. Day
303041 by: Robert P. J. Day
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Mattias Thorslund wrote:
Robert P. J. Day wrote:
(just a warning -- as a relative newbie to PHP, i'll probably have
the occasional dumb question. just humour me.)
i'm looking at some existing PHP code that accesses a mysql 5.0 db,
and it's coded using the mysql-specific calls: mysql_connect,
mysql_select_db, etc, etc.
is there any reason i *wouldn't* want to rewrite that code using the
more general PEAR DB module, and use mysqli? certainly, as i read it,
using the PEAR DB module would make it easier down the road if i
suddenly decide to change the DB backend.
anyway, any compelling arguments for or against?
rday
--
Well, the reason you shouldn't use PEAR DB in a new project is that it's
being deprecated. MDB2 is the PEAR successor, and does provide emulation
for some features that don't exist on all database platforms, such as
LastInsertID. It can also help you convert your database from one
platform to another, since it also provides methods for detecting and
managing the database structure itself (the Manager and Reverse modules).
That said, if I were to start a new project at this time, I would look
closer at whether PDO fits my needs.
I use MDB2.
I hear PDO hyped a lot, what does it really give me that MDB2 does not,
other than making the application dependent upon a binary module?
--- End Message ---
--- Begin Message ---
On 03/20/2010 02:31 AM, Michael A. Peters wrote:
Mattias Thorslund wrote:
Robert P. J. Day wrote:
(just a warning -- as a relative newbie to PHP, i'll probably have
the occasional dumb question. just humour me.)
i'm looking at some existing PHP code that accesses a mysql 5.0 db,
and it's coded using the mysql-specific calls: mysql_connect,
mysql_select_db, etc, etc.
is there any reason i *wouldn't* want to rewrite that code using the
more general PEAR DB module, and use mysqli? certainly, as i read it,
using the PEAR DB module would make it easier down the road if i
suddenly decide to change the DB backend.
anyway, any compelling arguments for or against?
rday
--
Well, the reason you shouldn't use PEAR DB in a new project is that
it's being deprecated. MDB2 is the PEAR successor, and does provide
emulation for some features that don't exist on all database
platforms, such as LastInsertID. It can also help you convert your
database from one platform to another, since it also provides methods
for detecting and managing the database structure itself (the Manager
and Reverse modules).
That said, if I were to start a new project at this time, I would look
closer at whether PDO fits my needs.
I use MDB2.
I hear PDO hyped a lot, what does it really give me that MDB2 does not,
other than making the application dependent upon a binary module?
binary module makes a lot of difference. If you use MDB2, the
interpreter has to compile MDB2's code along with your program logic.
Whereas PDO is already compiled one, so it will do the job much much faster.
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--- End Message ---
--- Begin Message ---
Nilesh Govindarajan wrote:
On 03/20/2010 02:31 AM, Michael A. Peters wrote:
Mattias Thorslund wrote:
Robert P. J. Day wrote:
(just a warning -- as a relative newbie to PHP, i'll probably have
the occasional dumb question. just humour me.)
i'm looking at some existing PHP code that accesses a mysql 5.0 db,
and it's coded using the mysql-specific calls: mysql_connect,
mysql_select_db, etc, etc.
is there any reason i *wouldn't* want to rewrite that code using the
more general PEAR DB module, and use mysqli? certainly, as i read it,
using the PEAR DB module would make it easier down the road if i
suddenly decide to change the DB backend.
anyway, any compelling arguments for or against?
rday
--
Well, the reason you shouldn't use PEAR DB in a new project is that
it's being deprecated. MDB2 is the PEAR successor, and does provide
emulation for some features that don't exist on all database
platforms, such as LastInsertID. It can also help you convert your
database from one platform to another, since it also provides methods
for detecting and managing the database structure itself (the Manager
and Reverse modules).
That said, if I were to start a new project at this time, I would look
closer at whether PDO fits my needs.
I use MDB2.
I hear PDO hyped a lot, what does it really give me that MDB2 does not,
other than making the application dependent upon a binary module?
binary module makes a lot of difference. If you use MDB2, the
interpreter has to compile MDB2's code along with your program logic.
Whereas PDO is already compiled one, so it will do the job much much
faster.
So since I already cash my db requests via APC the benefits to me would
be small.
--- End Message ---
--- Begin Message ---
On 03/20/2010 07:50 AM, Michael A. Peters wrote:
Nilesh Govindarajan wrote:
On 03/20/2010 02:31 AM, Michael A. Peters wrote:
Mattias Thorslund wrote:
Robert P. J. Day wrote:
(just a warning -- as a relative newbie to PHP, i'll probably have
the occasional dumb question. just humour me.)
i'm looking at some existing PHP code that accesses a mysql 5.0 db,
and it's coded using the mysql-specific calls: mysql_connect,
mysql_select_db, etc, etc.
is there any reason i *wouldn't* want to rewrite that code using the
more general PEAR DB module, and use mysqli? certainly, as i read it,
using the PEAR DB module would make it easier down the road if i
suddenly decide to change the DB backend.
anyway, any compelling arguments for or against?
rday
--
Well, the reason you shouldn't use PEAR DB in a new project is that
it's being deprecated. MDB2 is the PEAR successor, and does provide
emulation for some features that don't exist on all database
platforms, such as LastInsertID. It can also help you convert your
database from one platform to another, since it also provides methods
for detecting and managing the database structure itself (the Manager
and Reverse modules).
That said, if I were to start a new project at this time, I would look
closer at whether PDO fits my needs.
I use MDB2.
I hear PDO hyped a lot, what does it really give me that MDB2 does not,
other than making the application dependent upon a binary module?
binary module makes a lot of difference. If you use MDB2, the
interpreter has to compile MDB2's code along with your program logic.
Whereas PDO is already compiled one, so it will do the job much much
faster.
So since I already cash my db requests via APC the benefits to me would
be small.
Yeah the use of APC or Xcache, etc. would not make any difference
between PDO and MDB2 in terms of performance.
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 02:01:03PM -0700, Michael A. Peters wrote:
<snip>
>
> I use MDB2.
> I hear PDO hyped a lot, what does it really give me that MDB2 does not,
> other than making the application dependent upon a binary module?
Maybe nothing. But PDO is built-in and MDB2 isn't.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Hi
I'm setting up a development environment that runs multiple versions of php.
I'm looking a list of the compile option options for each php release
other than "./configure --help" with more detail on what each option
does.
Any suggestions welcome .
Thank you.
--- End Message ---
--- Begin Message ---
On 03/20/2010 03:16 AM, Gregory Machin wrote:
Hi
I'm setting up a development environment that runs multiple versions of php.
I'm looking a list of the compile option options for each php release
other than "./configure --help" with more detail on what each option
does.
Any suggestions welcome .
Thank you.
Its unclear what you want. This mailing list is not get ready made
things, but to get already made things fixed so that they do not produce
errors.
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--- End Message ---
--- Begin Message ---
On 20/03/2010, at 10:46 AM, Gregory Machin wrote:
> Hi
> I'm setting up a development environment that runs multiple versions of php.
> I'm looking a list of the compile option options for each php release
> other than "./configure --help" with more detail on what each option
> does.
> Any suggestions welcome .
>
> Thank you.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
From http://php.net/install.unix:
"The initial PHP setup and configuration process is controlled by the use of
the command line options of the configure script. You could get a list of all
available options along with short explanations running ./configure --help. Our
manual documents the different options separately. You will find the core
options in the appendix <http://php.net/configure>, while the different
extension specific options are descibed on the reference pages."
---
Simon Welsh
Admin of http://simon.geek.nz/
Who said Microsoft never created a bug-free program? The blue screen never,
ever crashes!
http://www.thinkgeek.com/brain/gimme.cgi?wid=81d520e5e
--- End Message ---
--- Begin Message ---
On Mar 18, 2010, at 1:26 PM, Andrew Ballard wrote:
On Thu, Mar 18, 2010 at 1:00 PM, Ashley Sheridan
<a...@ashleysheridan.co.uk> wrote:
[snip]
And I believe that when MS Office saves a CSV out with a character
other
than a comma as the delimiter, it still saves it as a .csv by
default.
Nope. If you save as CSV, it is comma-separated with double-quotes as
the text qualifier. There is also an option to save in tab-delimited
format, but the default extension for that is .txt.
The only issue I have with Excel handling text files is with columns
like ZIP code that should be treated as text (they are string
sequences that happen to contain only numeric digits where leading
zeros are significant) but are interpreted as numbers.
Andrew
Hi Andrew,
As a fellow mailing list processor I can feel your pain... One thing I
have found is when you are importing the data, you can select the zip
column and change the format from "general" to "text" and it will
maintain the leading zero's. Or a simple filter applied to it
afterwards will help to.
But if you have a decent CASS software then it should add the zip back
in hehe :)
--- End Message ---
--- Begin Message ---
On Fri, 2010-03-19 at 18:01 -0400, Jason Pruim wrote:
> On Mar 18, 2010, at 1:26 PM, Andrew Ballard wrote:
>
> > On Thu, Mar 18, 2010 at 1:00 PM, Ashley Sheridan
> > <a...@ashleysheridan.co.uk> wrote:
> > [snip]
> >> And I believe that when MS Office saves a CSV out with a character
> >> other
> >> than a comma as the delimiter, it still saves it as a .csv by
> >> default.
> >
> > Nope. If you save as CSV, it is comma-separated with double-quotes as
> > the text qualifier. There is also an option to save in tab-delimited
> > format, but the default extension for that is .txt.
> >
> > The only issue I have with Excel handling text files is with columns
> > like ZIP code that should be treated as text (they are string
> > sequences that happen to contain only numeric digits where leading
> > zeros are significant) but are interpreted as numbers.
> >
> > Andrew
>
>
> Hi Andrew,
>
> As a fellow mailing list processor I can feel your pain... One thing I
> have found is when you are importing the data, you can select the zip
> column and change the format from "general" to "text" and it will
> maintain the leading zero's. Or a simple filter applied to it
> afterwards will help to.
>
> But if you have a decent CASS software then it should add the zip back
> in hehe :)
>
>
It's not really just that. In the csv format, a field value of 00123 (I
don't really know what zip code formats are) is perfectly valid.
Unfortunately, Excel (and Calc) tries to be clever and strips out
leading zeros on a field it recognises as all numbers. This is annoying
for things like zip codes and phone numbers (which in the UK mostly all
start with a 0)
I think short of enclosing the field in quote marks to signify it's a
string and not something that the software should guess at is the only
way to ensure it works effectively.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 6:01 PM, Jason Pruim <li...@pruimphotography.com> wrote:
>
> On Mar 18, 2010, at 1:26 PM, Andrew Ballard wrote:
>
>> On Thu, Mar 18, 2010 at 1:00 PM, Ashley Sheridan
>> <a...@ashleysheridan.co.uk> wrote:
>> [snip]
>>>
>>> And I believe that when MS Office saves a CSV out with a character other
>>> than a comma as the delimiter, it still saves it as a .csv by default.
>>
>> Nope. If you save as CSV, it is comma-separated with double-quotes as
>> the text qualifier. There is also an option to save in tab-delimited
>> format, but the default extension for that is .txt.
>>
>> The only issue I have with Excel handling text files is with columns
>> like ZIP code that should be treated as text (they are string
>> sequences that happen to contain only numeric digits where leading
>> zeros are significant) but are interpreted as numbers.
>>
>> Andrew
>
>
> Hi Andrew,
>
> As a fellow mailing list processor I can feel your pain... One thing I have
> found is when you are importing the data, you can select the zip column and
> change the format from "general" to "text" and it will maintain the leading
> zero's. Or a simple filter applied to it afterwards will help to.
>
> But if you have a decent CASS software then it should add the zip back in
> hehe :)
>
>
That works - if I'm the first one to open the file. Often I get files
that someone else opened in Excel to "fix" some things then saved back
to CSV and sent merrily along. :-)
Andrew
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 6:13 PM, Ashley Sheridan
<a...@ashleysheridan.co.uk> wrote:
>
> On Fri, 2010-03-19 at 18:01 -0400, Jason Pruim wrote:
>
> On Mar 18, 2010, at 1:26 PM, Andrew Ballard wrote:
>
> > On Thu, Mar 18, 2010 at 1:00 PM, Ashley Sheridan
> > <a...@ashleysheridan.co.uk> wrote:
> > [snip]
> >> And I believe that when MS Office saves a CSV out with a character
> >> other
> >> than a comma as the delimiter, it still saves it as a .csv by
> >> default.
> >
> > Nope. If you save as CSV, it is comma-separated with double-quotes as
> > the text qualifier. There is also an option to save in tab-delimited
> > format, but the default extension for that is .txt.
> >
> > The only issue I have with Excel handling text files is with columns
> > like ZIP code that should be treated as text (they are string
> > sequences that happen to contain only numeric digits where leading
> > zeros are significant) but are interpreted as numbers.
> >
> > Andrew
>
>
> Hi Andrew,
>
> As a fellow mailing list processor I can feel your pain... One thing I
> have found is when you are importing the data, you can select the zip
> column and change the format from "general" to "text" and it will
> maintain the leading zero's. Or a simple filter applied to it
> afterwards will help to.
>
> But if you have a decent CASS software then it should add the zip back
> in hehe :)
>
>
>
> It's not really just that. In the csv format, a field value of 00123 (I don't
> really know what zip code formats are) is perfectly valid. Unfortunately,
> Excel (and Calc) tries to be clever and strips out leading zeros on a field
> it recognises as all numbers. This is annoying for things like zip codes and
> phone numbers (which in the UK mostly all start with a 0)
>
> I think short of enclosing the field in quote marks to signify it's a string
> and not something that the software should guess at is the only way to ensure
> it works effectively.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
I don't think even that works. I think what Jason suggested (going
through the text import wizard -- which does not always launch if you
just open the CSV file since Excel thinks it knows how to handle it --
and specifying to treat the column as text) is the only way to be
sure.
Andrew
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 10:13:54PM +0000, Ashley Sheridan wrote:
<snip>
>
> It's not really just that. In the csv format, a field value of 00123 (I don't
> really know what zip code formats are) is perfectly valid.
ZIP codes are simply five digits. The starting digit (0-9) identifies a
broad region of the country. The beginning 3-digit sequence identifies a
major processing center. A full 5-digit ZIP code can encompass a few
blocks or hundreds of square kilometers, depending on the density of
addresses (population). ZIPs ending in 98 or 99 are often reserved for
the Post Office itself.
Fascinating, huh? ;-}
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 06:01:38PM -0400, Jason Pruim wrote:
<snip>
>
> But if you have a decent CASS software then it should add the zip back
> in hehe :)
For the sake of those in Europe and elsewhere, CASS software is software
certified by the US Postal Service which cleans up addresses to conform
to what the Post Office wants them to look like, including adding
correct ZIP codes where possible. There is an additional kind of
software, called PAVE software, which sorts mailing lists into proper
groupings for simple delivery by the Post Office.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Robert P. J. Day wrote:
> i don't see a separate mailing list for documentation so is this
> where i would point at oddities in the manual? as in, here:
>
> http://www.php.net/manual/en/language.variables.external.php
>
> we read:
>
> "// Unavailable since PHP 6."
>
> that just looks weird, no?
>
> rday
> --
>
> ========================================================================
> Robert P. J. Day Waterloo, Ontario, CANADA
>
> Linux Consulting, Training and Kernel Pedantry.
>
> Web page: http://crashcourse.ca
> Twitter: http://twitter.com/rpjday
> ========================================================================
$HTTP_POST_VARS was the way to access post vars in PHP before 4.1. Since
then it is $_POST, and $HTTP_POST_VARS is only available if you set
register_long_arrays = On in php.ini. As of PHP 6 $HTTP_POST_VARS will
not be available, you must use $_POST.
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
On Fri, 19 Mar 2010, Shawn McKenzie wrote:
> Robert P. J. Day wrote:
> > i don't see a separate mailing list for documentation so is this
> > where i would point at oddities in the manual? as in, here:
> >
> > http://www.php.net/manual/en/language.variables.external.php
> >
> > we read:
> >
> > "// Unavailable since PHP 6."
> >
> > that just looks weird, no?
> >
> > rday
>
> $HTTP_POST_VARS was the way to access post vars in PHP before 4.1.
> Since then it is $_POST, and $HTTP_POST_VARS is only available if
> you set register_long_arrays = On in php.ini. As of PHP 6
> $HTTP_POST_VARS will not be available, you must use $_POST.
i'm not sure that addresses my post -- it doesn't make grammatical
sense to state that something is unavailable "since" something that is
yet to be officially released.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 16:59, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>
> i don't see a separate mailing list for documentation so is this
> where i would point at oddities in the manual? as in, here:
>
> http://www.php.net/manual/en/language.variables.external.php
>
> we read:
>
> "// Unavailable since PHP 6."
>
> that just looks weird, no?
Indeed. It would probably be better to read, "Unavailable as of
PHP 6." I'll patch that in the XML sources now, and the next time the
manual rebuilds, the changes will take effect.
For the future, please report such things as Documentation
Problems at http://bugs.php.net/.
Thanks for the report, Rob!
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Looking for hosting or dedicated servers? Ask me how we can fit your budget!
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 20:57, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>
> i'm not sure that addresses my post -- it doesn't make grammatical
> sense to state that something is unavailable "since" something that is
> yet to be officially released.
In most cases, you'd be absolutely correct.... but PHP is a
developer-focused open source project, so some folks in the community
do use PHP 6. If you'd like to be one of them, we'd certainly welcome
the extra help in finding and reporting bugs! You can always download
the latest snapshot builds at:
http://snaps.php.net/
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Looking for hosting or dedicated servers? Ask me how we can fit your budget!
--- End Message ---
--- Begin Message ---
On Fri, Mar 19, 2010 at 21:04, Daniel Brown <danbr...@php.net> wrote:
>
> Indeed. It would probably be better to read, "Unavailable as of
> PHP 6." I'll patch that in the XML sources now, and the next time the
> manual rebuilds, the changes will take effect.
Future builds will appear as hinted in the following SVN commit log:
http://news.php.net/php.doc.cvs/6235
Thanks again for the suggestion, Rob.
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Looking for hosting or dedicated servers? Ask me how we can fit your budget!
--- End Message ---
--- Begin Message ---
On Fri, 19 Mar 2010, Daniel Brown wrote:
> On Fri, Mar 19, 2010 at 16:59, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> > i don't see a separate mailing list for documentation so is this
> > where i would point at oddities in the manual? as in, here:
> >
> > http://www.php.net/manual/en/language.variables.external.php
> >
> > we read:
> >
> > "// Unavailable since PHP 6."
> >
> > that just looks weird, no?
>
> Indeed. It would probably be better to read, "Unavailable as of
> PHP 6." I'll patch that in the XML sources now, and the next time
> the manual rebuilds, the changes will take effect.
precisely the point i was trying to make, but i might avoid the use
of the word "unavailable" since that's still slightly ambiguous. it
makes it seem like it's still there somehow, you just can't get to it.
i would be more direct, something like "*removed* as of PHP 6." then
there's no confusion.
> For the future, please report such things as Documentation
> Problems at http://bugs.php.net/.
ok, will do.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--- End Message ---
--- Begin Message ---
On Fri, 19 Mar 2010, Daniel Brown wrote:
> On Fri, Mar 19, 2010 at 20:57, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> > i'm not sure that addresses my post -- it doesn't make grammatical
> > sense to state that something is unavailable "since" something that is
> > yet to be officially released.
>
> In most cases, you'd be absolutely correct.... but PHP is a
> developer-focused open source project, so some folks in the community
> do use PHP 6. If you'd like to be one of them, we'd certainly welcome
> the extra help in finding and reporting bugs! You can always download
> the latest snapshot builds at:
>
> http://snaps.php.net/
surely there's a svn checkout for the ongoing php 6, yes?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--- End Message ---
