Re: MySQL class. Thoughts?
| From: | Ashley Sheridan | Date: | Thu, 22 Jan 2009 00:07:03 +0000 |
| Subject: | Re: MySQL class. Thoughts? | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-286975@lists.php.net to get a copy of this message | ||
On Wed, 2009-01-21 at 18:52 -0500, Eric Butera wrote:
> On Wed, Jan 21, 2009 at 6:37 PM, Jochem Maas <jochem@iamjochem.com> wrote:
> > Chris schreef:
> >>
> >>>>> Yea if you're only targeting 1 db, then why not use that class? At
> >>>>> least then there's the php manual to figure out what something does.
> >>>> Because then to add query logging for the whole app, you just need to
> >>>> put it
> >>>> in the class :)
> >>>>
> >>>> (I've done that before to check what's being run and where from,
> >>>> comes in
> >>>> very handy).
> >>>>
> >>
> >>>
> >>> That's done by tail -f /var/log/mysql/query.log. :D
> >>
> >> That won't tell you where a query comes from ;) Add a debug_backtrace
> >> into the class to also pinpoint where the query was called from.
> >> Complicated queries built on variables (or even just long queries built
> >> over multiple lines) will be hard to find just by looking at the mysql
> >> query log.
> >>
> >
> > besides on shared hosting that log is often turned off even if you can get at it.
> >
> >
>
> That's why I set up a local dev environment. If something is wrong,
> just grab a db dump & figure it out locally. That way I can do
> whatever I need to really try out what the issue is and the best way
> to resolve it.
>
> Just merely saying how I develop. Whatever gets it done is the real way. :)
>
A DB dump won't always tell you where the problem lies. With proper
logging, you can use the DB dump to work out what went wrong precisely.
Ash
www.ashleysheridan.co.uk