Hi!
On Aug 8, 2008, at 6:43 PM, Brian Aker wrote:
On Aug 8, 2008, at 9:41 AM, Kay Röpke wrote:
Agreed, but I'd throw it out and add something else back in.
Something that returns a sane format (like a table!? :)). And
frankly parsing "show global statistics" or whatever isn't exactly
slow, it depends whether the backing data store is fast or not. I
don't think there's a need to have that on the protocol level at all.
What I am wondering is if in the future the stats should come from a
COM or a SQL call.
Seriously, I wouldn't want this on the protocol level because that
implies that changing the content of that command also requires a
change in the client lib.
Since a request to see stats is a data request, and this is a
database, what's more natural to return it as a table? Actually, I
think it should actually be a table proper, although one backed by a
table function, not a persistent one as its data is transient.
The only reason for having it in the protocol is speed: You can bypass
all other code (including parsing and validation). But I think this
comes at the cost of clarity: You then end up with multiple ways of
getting statistical information, one via the command (where cannot
easily specify which data you are interested in), multiple via SHOW
queries and possibly other ways of SELECTing that stuff.
My bias is towards simplicity in the interface, it allows for easy
retrieval and is largely self-explanatory.
cheers,
-k
--
Kay Roepke
Software Engineer, MySQL Enterprise Tools
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
