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
