Menu
▾
▴
chiphpug-discuss
|
From: jsWalter <jsW...@to...> - 2007-10-04 04:56:08
|
I'm rolling my own little DB class (pls, I don't need to hear about how wonder this or that class is, thank you, I've reading over 2 dozen such libaries) and I have a question to this group... Workflow: 1) submit data form 2) pull data from POST 3) "clean" data 4) update record Now, my question deals with step 3. On one hand, the cleansing of the data needs to be done by the developer. On the other, would it be logical for the DB class to take a whack at the data set and to make sure each field is the data type that the database is expecting? Or should the developer code that as well? Ideas? walter ==================================================== Taking it to the next level. web.torres.ws/dev/php/walters_way |
|
From: Larry G. <la...@ga...> - 2007-10-04 05:28:17
|
Enter the magic of prepared statements. I personally prefer to use PDO, since I like it's interface better than MySQLi's and it supports both named and unnamed parameters. http://www.php.net/pdo It requires PHP 5.1 or later. If you're using an earlier version of PHP, you need to be smacked because anything older than that is dead and the funeral is in process: http://gophp5.org/ http://www.php.net/index.php#2007-07-13-1 Note that if you're using a database other than MySQL, you'll run into some field types that still need special handling. Most notable is LOBs in Oracle and DB2, since those databases still think it's 1988. On Wednesday 03 October 2007, jsWalter wrote: > I'm rolling my own little DB class (pls, I don't need to hear about how > wonder this or that class is, thank you, I've reading over 2 dozen such > libaries) and I have a question to this group... > > Workflow: > 1) submit data form > 2) pull data from POST > 3) "clean" data > 4) update record > > Now, my question deals with step 3. > > On one hand, the cleansing of the data needs to be done by the developer. > > On the other, would it be logical for the DB class to take a whack at the > data set and to make sure each field is the data type that the database is > expecting? Or should the developer code that as well? > > Ideas? > > walter > > > > > ==================================================== > Taking it to the next level. > web.torres.ws/dev/php/walters_way > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss -- Larry Garfield AIM: LOLG42 la...@ga... ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson |
|
From: Neil Y. <ny...@as...> - 2007-10-04 13:39:23
|
I think prepared statements are the best way to go, assuming that Walter = is using MySQL. Walter, if you are using another database that doesn't = support prepared statements, such as MS SQL Server, then my approach would be to minimally do data type validation on step 3 - this is also a location = that you could ensure other kinds of data integrity if you so choose. Neil -----Original Message----- From: chi...@li... [mailto:chi...@li...] On Behalf Of = Larry Garfield Sent: Thursday, October 04, 2007 12:28 AM To: chi...@li... Subject: Re: [chiPHPug-discuss] DB Class workflow question Enter the magic of prepared statements. I personally prefer to use PDO, since=20 I like it's interface better than MySQLi's and it supports both named = and=20 unnamed parameters. http://www.php.net/pdo It requires PHP 5.1 or later. If you're using an earlier version of = PHP, you=20 need to be smacked because anything older than that is dead and the = funeral=20 is in process: http://gophp5.org/ http://www.php.net/index.php#2007-07-13-1 Note that if you're using a database other than MySQL, you'll run into = some=20 field types that still need special handling. Most notable is LOBs in Oracle=20 and DB2, since those databases still think it's 1988. On Wednesday 03 October 2007, jsWalter wrote: > I'm rolling my own little DB class (pls, I don't need to hear about = how > wonder this or that class is, thank you, I've reading over 2 dozen = such > libaries) and I have a question to this group... > > Workflow: > 1) submit data form > 2) pull data from POST > 3) "clean" data > 4) update record > > Now, my question deals with step 3. > > On one hand, the cleansing of the data needs to be done by the = developer. > > On the other, would it be logical for the DB class to take a whack at = the > data set and to make sure each field is the data type that the = database is > expecting? Or should the developer code that as well? > > Ideas? > > walter > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Taking it to the next level. > web.torres.ws/dev/php/walters_way > > > = -------------------------------------------------------------------------= > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a = browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > chiPHPug-discuss mailing list > chi...@li... > https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss --=20 Larry Garfield AIM: LOLG42 la...@ga... ICQ: 6817012 "If nature has made any one thing less susceptible than all others of=20 exclusive property, it is the action of the thinking power called an = idea,=20 which an individual may exclusively possess as long as he keeps it to=20 himself; but the moment it is divulged, it forces itself into the = possession of every one, and the receiver cannot dispossess himself of it." -- = Thomas=20 Jefferson -------------------------------------------------------------------------= This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ chiPHPug-discuss mailing list chi...@li... https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss |
|
From: Jason R. <ja...@ho...> - 2007-10-04 14:13:21
|
As a potential counter to the prepared statement path, one problem is that mysqli precludes persistent connections. In certain large scale architectures persistent connections have a big benefit. In the hands of developers that dont understand the entire system architecture and/or don't have control over all aspects of it (any shared hosting environment for example), prepared statements can be harmful. Precluding their use just for data input validation is throwing out a useful tool in the scaling toolbox that you may need in the future. That matters only if their is a possibility that you will need massive scale in this DB handler. One approach that I suggest is keeping user input validation near its input handler and keeping DB protection minimal (i.e. something like escape). The reason being that you want both business logic validation (i.e. email address can't be NULL here) and data field validation (email address can't contain the '#' char) to be handled consistently and leverage any common user error dialogs or exception handling routines correctly. This is squarely in the user-facing application logic portion and not in your data persistence layer (unless you are an Orcale monkey and then half your app logic is in your stored procedures and triggers). Neil Young wrote: > I think prepared statements are the best way to go, assuming that Walter is > using MySQL. Walter, if you are using another database that doesn't support > prepared statements, such as MS SQL Server, then my approach would be to > minimally do data type validation on step 3 - this is also a location that > you could ensure other kinds of data integrity if you so choose. > > Neil > > -----Original Message----- > From: chi...@li... > [mailto:chi...@li...] On Behalf Of Larry > Garfield > Sent: Thursday, October 04, 2007 12:28 AM > To: chi...@li... > Subject: Re: [chiPHPug-discuss] DB Class workflow question > > Enter the magic of prepared statements. I personally prefer to use PDO, > since > I like it's interface better than MySQLi's and it supports both named and > unnamed parameters. > > http://www.php.net/pdo > > It requires PHP 5.1 or later. If you're using an earlier version of PHP, > you > need to be smacked because anything older than that is dead and the funeral > is in process: > > http://gophp5.org/ > http://www.php.net/index.php#2007-07-13-1 > > Note that if you're using a database other than MySQL, you'll run into some > field types that still need special handling. Most notable is LOBs in > Oracle > and DB2, since those databases still think it's 1988. > > On Wednesday 03 October 2007, jsWalter wrote: >> I'm rolling my own little DB class (pls, I don't need to hear about how >> wonder this or that class is, thank you, I've reading over 2 dozen such >> libaries) and I have a question to this group... >> >> Workflow: >> 1) submit data form >> 2) pull data from POST >> 3) "clean" data >> 4) update record >> >> Now, my question deals with step 3. >> >> On one hand, the cleansing of the data needs to be done by the developer. >> >> On the other, would it be logical for the DB class to take a whack at the >> data set and to make sure each field is the data type that the database is >> expecting? Or should the developer code that as well? >> >> Ideas? >> >> walter >> >> >> >> >> ==================================================== >> Taking it to the next level. >> web.torres.ws/dev/php/walters_way >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> chiPHPug-discuss mailing list >> chi...@li... >> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss > > |
|
From: Anacreo <an...@gm...> - 2007-10-04 05:43:02
|
Hmm that's a tricky one Walter... it depends on what the intention is of
your class? Say I build a logging class, I'll generally throw in options
such as "autodelete" (delete the physical log file on destruct), "echowrite"
(write to stdout on log write), "htmllog" (store the log in a buffer as
html), "bufferlog" (buffer the log)... anyhow I digress my point is if you
want to write a nice class with handy dandy features that is re-useable
(even by just you)... make them optionable.
So I see value in writing your own wrapper DB class (I'd still incorporate
the PDO library or similar into yours). So my options might be:
datatypes_enforce
datatypes_cache = &somesort of cookied variable (or possibly a path to a
datafile if you'd rather have your class manage it in that way)
so some pseudo code might be:
...
$safedb = new safedb();
$safedb->datatypes_enforce = true;
...
I would point out caching the data types as you will need to do a query
before doing your select if you don't. So if I have some sort of server
side cookie sessions going I may store some tables datatypes there, this can
significantly speed up your site.
In the past I've also used mapping tables with regex for a situation like
this as well:
$safedb->validate['tablename']['column'] = '/^[0-9+/()- ]*$/';
or
$safedb->format['tablename']['column'] = 's/\s+//g';
The one bad/positive to this is that you might prefer to pass your data as
an associative array instead of a SQL statement, ie:
set $nugget['user'] = array(
'user' => $user,
'passwd' => "crypt(" . $pass . ")"
);
$result = $safedb->write($nugget)
Not sure if this was the kind of feedback you're looking for.
On 10/3/07, jsWalter <jsW...@to...> wrote:
>
>
> I'm rolling my own little DB class (pls, I don't need to hear about how
> wonder this or that class is, thank you, I've reading over 2 dozen such
> libaries) and I have a question to this group...
>
> Workflow:
> 1) submit data form
> 2) pull data from POST
> 3) "clean" data
> 4) update record
>
> Now, my question deals with step 3.
>
> On one hand, the cleansing of the data needs to be done by the developer.
>
> On the other, would it be logical for the DB class to take a whack at the
> data set and to make sure each field is the data type that the database is
> expecting? Or should the developer code that as well?
>
> Ideas?
>
> walter
>
>
>
>
> ====================================================
> Taking it to the next level.
> web.torres.ws/dev/php/walters_way
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> chiPHPug-discuss mailing list
> chi...@li...
> https://lists.sourceforge.net/lists/listinfo/chiphpug-discuss
>
|
|
From: Peter H. <ph...@ma...> - 2007-10-04 15:16:41
|
On Wed, Oct 03, 2007 at 11:56:04PM -0500, jsWalter wrote: > I'm rolling my own little DB class (pls, I don't need to hear about how > wonder this or that class is, thank you, I've reading over 2 dozen such > libaries) and I have a question to this group... This, right here, is why I like reinventing wheels. You'll find yourself making design decisions that you initially didn't even notice that library creators had made. You gain a deeper understanding of the problem. (And then when I have a deep understanding I almost always throw away my code and make an now-informed choice of libraries.) > On the other, would it be logical for the DB class to take a whack at the > data set and to make sure each field is the data type that the database is > expecting? Or should the developer code that as well? Give the developer the raw data, exactly as it came in from the user, otherwise you'll make some really useful non-reversable transformation that, six months from now, you realize is a big pain for some code you're adding. When the developer calls the API again to save to the database, that's where your code should step in to make sure that integer fields are not getting passed strings and so on. Let the API escape data and pass it to the database, then capture the database's errors and raise meaningful exceptions to the developer. This way you prevent SQL injection and don't have to reinvent all the checking the database does. -- Peter Harkins - http://push.cx - http://NearbyGamers.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X