On Thu, Dec 18, 2008 at 4:05 PM, Brian Aker <[email protected]> wrote:
> Should we support catalogs? I've been going back and forth about this. At
> the moment they really are not supported... the work to do them was never
> merged into 5.0. They are just reserved for the future.
>
> Multi-tenancy is the issue for me. Should a user(s) be given a catalog?
> Should we just restrict this to schema? Should joins work across them?

my understanding is that 'schema' sort of maps to user in some
databases. i will admit i am fairly ignorant of other databases, just
that the reason that jdbc (and odbc) mapped mysql's databases to
catalogs instead of schemas is that they behave more like people
expect catalogs to do. or so i remember being told.

> Is a catalog a simple namespace issue?
>
> If we can get Innodb to stop doing a few things globally we could allow one
> server to have multiple Innodb instances internally... every catalog could
> have its own (as an example).
>
>> drizzle could avoid the horrible slowness of information_schema, and
>
> In the current roadmap is to rework I_S so the are not materialized (and use
> the same execution path as the engine).

as long as querying the COLUMNS table with a "WHERE TABLE_NAME LIKE
... AND SCHEMATA_NAME = .." clause doesn't open every .frm or discover
every table from every engine, you'll be ahead of the game.

>> some of the impedance mismatches between what is available from the
>> server and what the standard apis expect to have available.
>
> What else are you thinking of?

the first one that comes to mind is that there's no sane way to get
the information for odbc's SQLGetTablePriviliges() function. there's
no reasonable way from the client side to know what sort of access you
have to a table without trying to do things to the table.

it's worth looking over the jdbc and odbc metadata functions to see
the sorts of data that people will expect to be able to get easily.

i don't recall what the plans are for drizzle and foreign keys, but
that is one of the uglier things that the connectors had to deal with
-- parsing table comments to figure out the foreign keys is no fun,
and getting the information from I_S is sloooow.

jim

_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help   : https://help.launchpad.net/ListHelp

Reply via email to