ourdelta-developers team mailing list archive

[Arjen Lentz <arjen@xxxxxxxxxxxxxxxx>]

Hi Mark

On 20/10/2008, at 12:25 AM, MARK CALLAGHAN wrote:
> On Sun, Oct 19, 2008 at 5:50 AM, Arjen Lentz  
> <arjen@xxxxxxxxxxxxxxxx> wrote:
> > Found & fixed, pushed in
> > https://code.launchpad.net/~arjen-lentz/ourdelta/ourdelta-userstatsv2
> >
> > Apart from the useful exercise for me (I'm sooo rusty), I decided  
> > it has
> > real-world relevance.
> > Chances are some people will have tables or columns named  
> > user_statistics or
> > client_statistics, and thus their application would break the  
> > moment they
> > start using a MySQL built with this patch.
> >
> > And then I also found the FLUSH SLOW QUERY LOGS addition hiding  
> > inside this patch.
> > Also fixed up the keyword there, people are bound to have some  
> > identifier named `logs`.
> > I extracted it to be separate, and documented both (some based on  
> > your wiki page)
>
> I think we eventually switched back to FLUSH SLOW QUERY LOG to avoid  
> that problem.

Sorry typo on my part; the newly introduced reserved word from this  
patch was `slow` so that's the one I fixed up.
LOGS already existed as a keyword (but is not a reserved word) so that  
wasn't a problem.

Can't just make it LOG (singular) as that's a function keyword, parser  
doesn't like that.
Could be missing something but not sure it can be done at all.
You say you made that change?

We could just make a SLOW_QUERY_LOG symbol and not have it as reserved  
word. All clean.
I might do that, but please let me know if indeed you did make the  
separate singular form work.


> > Question, Mark: some of the userstats appears to be MyISAM/InnoDB  
> > specific
> > (there's code in ha_myisam.cc and ha_innodb.cc), is there a  
> > specific reason
> > for this (like required info not available outside), or could it  
> > possibly be
> > made generic for all engines?
> > I'll want to document this fact, as for instance PBXT might want to  
> > add in
> > foo to be included also.
> > Thanks
>
> I think that you can do all of this in handler.{cc,h} but it might
> require a lot of changes. I prefer that all of the counting be done in
> handler.{cc,h} but that requires that the existing methods to
> read/insert/update/delete a row be helper methods and not get called
> directly by non-handler code. Non-handler code should call the new
> methods in handler.{cc,h} that increments the count and calls the
> helper. But to make this work, either non-handler code has to be
> changed to call methods with new names or all engines have to be
> changed. It is probably easier to change non-handler code.
>
> We haven't been willing to make those changes yet.

Understood.


Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com.au/)
Training and Expertise for MySQL in Australia and New Zealand

OurDelta: free enhanced builds for MySQL @ http://ourdelta.org/