On Wed, Oct 22, 2008 at 4:53 AM, Monty Taylor <[EMAIL PROTECTED]> wrote:
> I think Stewart's question was - now that we've gotten rid of a central > system database, if we were to store data about tablespaces, where would > we keep it? > Though the central system database (known as "mysql" in the MySQL install) is gone, Stewart's question had nothing to do with that fact. Currently the way mysql knows about databases is to look for directories in $datadir. I don't believe that $datadir is stored in the central system database anywhere, though it is read and cached on mysqld startup (and therefore probably on drizzled startup). Same with tablespaces -- InnoDB metadata tablespaces (commonly named ibdata1, ibdata2) are also specified in the config file, which has nothing to do with a central system database. Same with the data/index tablespaces -- stored in $datadir for innodb_file_per_table (otherwise, data/indexes are stored in the metadata tablespace). InnoDB specifies its own way to store and find tablespaces, why can't Drizzle do the same with databases? The problem I have is that MySQL makes "finding databases" a very hacky thing. It means that case-sensitivity may or may not matter in database names (yes, we've solved this in Drizzle, but that's not the point). It means we get databases like "lost+found" and "OLD", because there are directories there. It's a bad hack. Hardcoding Drizzle to say "all directories underneath $datadir are considered databases" is a bad idea. Drizzle should have meaningful database metadata beyond "schema_name". schema_location for example. If MyISAM works the same in Drizzle, fine -- but I'd say with the caveat that it looks in $myisam_datadir instead of a global $datadir. (ie, if individual engines want to keep the hacky way of "finding" tables by looking for .frm files, that's up to the engines. But having non-global parameters is important. In this scenario, we could have $myisam_datadir and $innodb_datadir and $csv_datadir if we really wanted. Ideally though the engines will be more flexible than that and instead of dumbly looking for $datadir/dbname/tblname.frm, it will be smarter about it. We have control over Drizzle, not necessarily the engines. Let's not make Drizzle's database discovery as hacky as MySQL's is. This may be hard, but I think it's very much worth it. And in general, Drizzle shouldn't care about the underlying filesystem (wrt symlinks and stuff). If possible, it should "just work". -Sheeri
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
