Hi!
If you focus first on turning the current ones into plugins, I think
you will find that the rest will fall into place.
Cheers,
--Brian
On May 31, 2009, at 9:53 AM, "Padraig O'Sullivan" <[email protected]
> wrote:
On Sun, May 31, 2009 at 11:00 AM, Jay Pipes <[email protected]> wrote:
Padraig O'Sullivan wrote:
Hi Jay,
I've started documenting the current I_S implementation and have a
rough outline of a project plan on the wiki page I created for my
GSoC
project. If you could have a quick look at it sometime and let me
know
if you see anything wrong with it or something that you would like
changed, that would be awesome:
http://drizzle.org/wiki/GSOC_Information_Schema
Now that I've spent some time looking at the current I_S
implementation, I'm starting to think a little more about how to
move
forward and I'm looking for any input on that. In particular, if you
look at section 4.3 of the wiki page, you will see I have a little
text on some thoughts I have on an I_S design (very rough at the
moment). If you have any time to have a look at that and share your
opinion, that would be really helpful!
Hi! Sorry for the delay in getting back to you on this!
No worries!
OK, here is my thought on the INFORMATION_SCHEMA "plugin". I
actually don't
think the INFORMATION_SCHEMA should be a plugin at all, but rather
expose a
plugin interface for its storage mechanism.
What the heck do I mean by this?
Well, what I mean is that the INFORMATION_SCHEMA isn't something that
changes -- the INFORMATION_SCHEMA interface is simply a standard
method of
retrieving system data via a SQL SELECT interface.
There is, therefore, no need to have multiple implementations of the
INFORMATION_SCHEMA interface. There is, however, a need to swap
out the
storage backend of the INFORMATION_SCHEMA -- think: I_S stored in
InnoDB,
I_S stored in memcached, etc.
For much of this, we already have a decent plugin API: the storage
engine
Handler interface. What I think is a good next step is to provide
a base
I_S_Storage plugin which would allow developers to switch out the
backend
storage seamlessly, even using multiple backends simultaneously --
think:
memcached backend for global variable counters, InnoDB backend for
recovery/backup persistence, MEMORY storage engine backend for most
all
other I_S tables...
So you are effectively saying that where the metadata I_S operates on
is stored should be pluggable? I'm starting to get a little confused
now as I know that Stewart is working on pluggable metadata stores
right? How does his work fit in what you are outlining here?
Don't worry too much about the stuff in show.cc right now. Most of
that
should go away entirely once I_S behaves like a normal schema and
follows
the handler API properly...
Thoughts?
Is the idea of using a system catalog i.e. base tables in a SYSTEM
database and defining views over those base tables to represent I_S
not worth considering here? I realise support for views is still
absent but I wanted to ask why we are not considering this approach.
The hardest part would be designing the system catalog and its
interfaces. Once we had a catalog in place, defining the I_S views on
top of it would be pretty straightforward.
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
