php-general Digest 13 Nov 2011 17:40:25 -0000 Issue 7565
Topics (messages 315661 through 315665):
Re: question about best practice for coding sql statements
315661 by: Geoff Shang
315664 by: tamouse mailing lists
Re: mysqli question
315662 by: Tommy Pham
315663 by: Peet Grobler
speeding up heavy web apps with a php-js cache manager
315665 by: rene7705
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 ---
On Sat, 12 Nov 2011, tamouse mailing lists wrote:
I'm curious how others feel about this. When I'm creating an SQL
string, either for a non-prepared or prepared execution, I build it in
a variable and then pass the variable to the query or prepare
function. This lets me easily add something to view the SQL statement,
and also if there's an error, emit the SQL statement.
I do this. This means that when a user encounters an error, they can
actually give you a meaningful error report which should reduce the time
it takes to fix it by a considerable amount.
Geoff.
--- End Message ---
--- Begin Message ---
On Sat, Nov 12, 2011 at 7:01 AM, Stephen <stephe...@rogers.com> wrote:
> While I am not a big fan of OOP, I do like PDO, and recommend its use.
Right -- I wasn't actually inquiring about how to access a data base,
merely the pactice of using a variable for the SQL -- In your example,
you are doing this as well, which fits in fine with what I was
enquiring about.
--- End Message ---
--- Begin Message ---
On Sat, Nov 12, 2011 at 6:15 AM, Peet Grobler <p...@hivemind.net> wrote:
> Not sure if this is the correct mailing list to be asking this question
> but here goes:
>
> I've got a prepared statement.
>
> $stmt = $dbh->prepare ("insert into test values (?, ?)")
> or die ("Error: " . $dbh->error);
> $stmt->bind_param ('ii', $var1, $var2)
> or die ("Error: " . $dbh->error);
> $stmt->execute()
> or die ("Error: " . $dbh->error);
>
> Okay I've taken the "or die" statements and put it into a function
> called 'db_error'. So it looks kinda like this:
>
> or db_error ($dbh, $__FILE__, $__LINE__);
>
> My db error then prints out "$dbh->error" and FILE and LINE variables so
> I know exactly where the error is.
>
> I would, however, love to print out the actual SQL text that failed.
> There's no way to determine it, the closest way I can think of is using
> a $sql variable holding the 'prepare' sql - but that's not what's going
> to the database.
>
> On a mysqli error - I can only see the actual sql that caused the
> problem on the development system, as mysql logging is turned on on
> that. It's not possible to turn on on the live system the overhead would
> probably kill us.
>
> Anyone found a way to do this?
>
> Peet
>
Depends on your overall application design. Meaning if you got
database abstraction layer in place to handle all your DB access or
the code snippet you've provided is used directly in a file. In
either case, the same concept applies but details of approach are
different.
* store the SQL statement string into a variable
* in your error handler, access that variable and send it to where you need to
Thus, this:
> $stmt = $dbh->prepare ("insert into test values (?, ?)")
> or die ("Error: " . $dbh->error);
becomes
$sql = "insert into test values (?, ?)";
$stmt = $dbh->prepare ($sql) or db_error ($dbh, __FILE__, __LINE__, $sql);
function db_error(object $dbh = null, $file, $line, $sql)
{
/* do what you need with it here */
}
> or db_error ($dbh, $__FILE__, $__LINE__);
__FILE__ are reserved keywords __LINE__. If you intended to use
variables represent the similar meaning, the suggested approach would
be $file and $line respectively. It would make things easier to read
and less confusing when you're troubleshooting, IMO.
If you have everything done in classes [1] and put all your DB access
in an abstraction layer class, you can use Exception [2] and get stack
traces [3] to better handle and troubleshoot any errors. [4] is the
non OOP way of error handling, IMO less elegant approach.
Best regards,
Tommy
[1] http://php.net/language.oop5
[2] http://php.net/language.exceptions
[3] http://php.net/exception.gettrace
[4] http://php.net/ref.errorfunc
--- End Message ---
--- Begin Message ---
On 2011-11-13 1:42 AM, Tommy Pham wrote:
>> or db_error ($dbh, $__FILE__, $__LINE__);
>
> __FILE__ are reserved keywords __LINE__. If you intended to use
> variables represent the similar meaning, the suggested approach would
Yes, sorry, was a bit quick there - I'm using __FILE__ __LINE__ to
indicate the file/line where the query failed to the error-handling
function.
--- End Message ---
--- Begin Message ---
Hi.
I'm developing a CMS, with lots of javascript code.
I haven't been satisfied with my page initialization speeds, so I've
started on a caching system.
First, i used to call up javascript as needed, and just-in-time. But that,
on a localhost setup, results in a second and a half delay.
So now I include all javascript for the entire CMS as inline js in the
<head> of index.php. Index.php gets gzipped of course.
The difference is really noticeable, without looking at any counters even.
So far so good.
Now I'd like to implement a caching system for ajax requests.
I was thinking to take URL, GET, and POST send parameters, and compare such
a set to items in a local js cache.
If the local cache is not available, the ajax request is sent as normal,
and the result is put in the cache.
Javascript implementation could be as easy as changing
jQuery.ajax(ajaxCommand) to cacheManager.ajax(ajaxCommand)
If the local cache is available, the onSuccess handler of the ajax request
is called with the cached data.
On the server end, the cached items are put in a global JSON "FAT" file,
again with URL, GET and POST as keys to a flat plaintext filename.
On the server, any "normal" ajaxable URL will call php code to update the
server end cache.
Index.php would query the cache for a "subscription", a list of cache
URL+GET+POST keys, and include these cached items as
<div id="cache_idx" style="display:none"><!-- {"keys" :
{URL+GET+POST+LAST_MODIFIED}, "data" : "cached-data"} --></div>
>From where the javascript cache manager would be able to find the data.
The javascript cache manager would include some kind of polling system, to
get near realtime updates for it's cached data.
I'm convinced caching of ajax results would further increase my page
initialization speeds.
I'm interested to learn about potential pitfalls, any opensource libraries
that already do this, or any other tips you can think of.
Thanks for your time.
--- End Message ---
