Re: adding bug info infront of sql query

From: Date: Mon, 12 Jan 2004 19:08:41 +0000
Subject: Re: adding bug info infront of sql query
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-25011@lists.php.net to get a copy of this message
Daniel Convissor wrote:
I've found it easier to check to see whether a query is a 'SELECT' query and otherwise assume that it's a manip query.
But, don't forget about SELECT INTO. Yes, that's true -- good point. I guess either way it's pretty hard to guess. I've had to deal w/ many scripts that have complex IF-THEN stuff (in MS SQL Server) before CREATE statements, making me believe that it's just gonna be very difficult to know whether a query is select or update -- especially in an RDBMS-agnostic way.
Is there a way to postpone the designation of ismanip() until after the query is executed? If the query is successful then the return value (resource vs true) should indicate what type of query it was, right? If query was unsuccessful, then _isManip() could guess -- not sure it's as crucial at that point. That's just an idea, though -- haven't looked at the source to know whether that makes sense.
Of course, I still think the better solution is to let developers specify to avoid the regexp.
You mean your proposal to use two different methods -- manipQuery() and selectQuery()? Or do you mean something else? Yeah, that's right. I think it makes sense to do it this way because there is going to be a difference in the expected return anyway. By that, I mean that as a developer I'm going to call query() differently for select statement vs an update statement:
$rs = $db->query("SELECT *..."); while($row = $rs->fetchRow()) { ... } vs. $ok = $db->query("UPDATE ..."); I do still think there needs to be a generic function, but that it doesn't have to be the only way to execute statements. Hans

« previous php.pear.dev (#25011) next »