PHP Pear - Re: [PEAR] DB_DataObject Generator creates PHP syntax breaking code

Author

Re: [PEAR] DB_DataObject Generator creates PHP syntax breaking code

Justin Patrin

2007-01-10, 10:02 pm

On 1/10/07, Simon <simon@tattoomachines.de> wrote:
> I'm using a MSSql (I have to) server witch has colum names like "E-Mail" oder "EG Number".
>
> The Generator creates my DataObject-files with contents like this:
> ...
> public $Telefax; // varchar(25)
> public $E-Mail; // varchar(60)
> public $Internet; // varchar(60)
> public $EG Number; // varchar(30)
> ...
>
> This breaks the PHP syntax of variable names. Because it uses "-" and " "!
> How can I prevent this or working arround, there are only a few "wrong" variables.

Well, I suggest not using those kind of column name sint he first
place. but DB_DO should be able to handle this. Are you using the
newest version fo DB_DataObject?

--
Justin Patrin

David Sanders

2007-01-10, 10:02 pm

Yeah I avoid anything that is invalid for a php variable in my column names.
The regular expression for a variable name is:

^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$

The generator could perhaps flag an error if it fails this regular expression or
even just replace bad characters with an underscore (which could possibly lead
to duplicated column names if people were silly enough to have "E-Mail" and
"E_Mail" in the same table)

Does Alan read this list?

Justin Patrin wrote:
> On 1/10/07, Simon <simon@tattoomachines.de> wrote:
>
> Well, I suggest not using those kind of column name sint he first
> place. but DB_DO should be able to handle this. Are you using the
> newest version fo DB_DataObject?
>

--
David Sanders

Simon

2007-01-11, 8:02 am

----- Original Message -----
From: "Justin Patrin" <papercrane@gmail.com>
To: "Simon" <simon@tattoomachines.de>
Cc: <pear-general@lists.php.net>
Sent: Thursday, January 11, 2007 3:31 AM
Subject: Re: [PEAR] DB_DataObject Generator creates PHP syntax breaking code

> On 1/10/07, Simon <simon@tattoomachines.de> wrote:
oder "EG Number".[color=darkred]
"![color=darkred]
variables.[color=darkred]
>
> Well, I suggest not using those kind of column name sint he first
> place. but DB_DO should be able to handle this. Are you using the
> newest version fo DB_DataObject?
>
> --
> Justin Patrin

I'm using DB_DataObject 1.8.5 (newest) and PHP 5.2 on Win XP.

Alan Knowles

2007-01-15, 4:02 am

Yes, this needs to be filed as a bug - it should raise an error on the
generator.

Re-writing column names at runtime, strikes me as a bit of a performance
hit, so I dont think implementing support for this is a good idea.

(I'm on digest for pear.general - so It may be a day or two before I
reply on some stuff)

Regards
Alan

David Sanders wrote:
> Yeah I avoid anything that is invalid for a php variable in my column
> names. The regular expression for a variable name is:
>
> ^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$
>
>
> The generator could perhaps flag an error if it fails this regular
> expression or even just replace bad characters with an underscore (which
> could possibly lead to duplicated column names if people were silly
> enough to have "E-Mail" and "E_Mail" in the same table)
>
> Does Alan read this list?
>
> Justin Patrin wrote:
>
>

Simon Brüchner

2007-01-15, 8:01 am

I opend a bug for this problem at http://pear.php.net/bugs/bug.php?id=9839

--
http://www.kolchose.org/simon/ajaximagemapcreator/

----- Original Message -----
From: "Justin Patrin" <@gmail.com>
To: "Alan Knowles" <@akbkhome.com>
Cc: <@lists.php.net>; "David Sanders" <@baselinesolutions.com.au>
Sent: Monday, January 15, 2007 4:30 AM
Subject: Re: [PEAR] DB_DataObject Generator creates PHP syntax breaking code

> On 1/14/07, Alan Knowles <@akbkhome.com> wrote:
>
> True, but not allowing them seems bad too. DB_DO_FB already done some
> column/table rewriting itself to support this kind of thing.
>
(which[color=darkred]
and[color=darkred]
>
>
> --
> Justin Patrin
>
> --
> PEAR General Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

Alan Knowles

2007-01-16, 4:01 am

I've closed the bug, and added a warning to the generator.

The only way to handle this gracefully, would to do something like

tableMap.ini
[mytable]
Email = "E-Mail"
EG_Number = "EG Number"
.....

Then load the table up at when needed and any reference to the table
column name would be replaced with the correct version (both in query
building, and returning data.)

Obviously this would be quite an overhall on the code, and prone to
problems. Let alone the issues with performance, that it has to check
the map on each fetch..

My thoughts on the best way to implement it would go something like this:
-> at the start of any method that deals with column names, a check
would be made to see if the map exists, then it would use a seperate
class to do all the work.:
eg.
if (!empty($options['column_mapper'])) {
return DB_DataObject_ColumnMapper::buildConditi
on();
}
....

If someone wants to work out a patch/class I guess I could add it.

Regards
Alan

Justin Patrin wrote:
> On 1/14/07, Alan Knowles <alan@akbkhome.com> wrote:
>
> True, but not allowing them seems bad too. DB_DO_FB already done some
> column/table rewriting itself to support this kind of thing.
>
>
>

Sponsored Links