On 01/06/11 16:15, Simon Helsen wrote:
Hi,

I am currently working on a patch which allows an SDB client to set a
schema on the SDBConnection (based on sdb 1.3.2). Unfortunately, it is
quite a bit of work since SDB code is not well abstracted over the table
names. However, we need it for a few reasons:

1) compliance in our infrastructure (i.e. we are not allowed to use user
schemas - the typical default for most databases)
2) the ability to setup more than one SDB within one database. The use of
schemas permits this setup and this would be an adoption blocker for us
3) it is generally not easy in our deployment to figure out what user name
is used to create tables. At the same time, some db commands (optimization
calls typically) require schema names, so control of the schema names
helps a lot here

The patch I am working on is backward compatible, i.e. if you don't set
the schema, the behavior should be as before. I don't know yet if I will
be able to contribute it (I need internal approval for that first).
However, conceptually it is not difficult, it is just a lot of work to
scan the code and find all the right spots

my question: is there some specific reason why this option was not
considered? Was it just because nobody asked for it?

thanks,

Simon ([email protected])

Sound good.

No specific reason I can recall - but it was a while ago.

There may be a JDBC interaction as the connection goes (usually) to the database and database == schema in some systems. (In MySQL I think then memrely makes it the default and you can name other databases.)

Anyone know more?

In PostgreSQL it is "database.schema.table" (from reading the doc just now) at the most general; MySQL is "schema.table".

The H2 document suggest it supports "schema.table" but the synatx rule isn't clear to me.


On 2: a while ago, TopQuadrant mentioned wanting and doing multiple SDB datasets per database. I don't know what became of this but maybe there is common experience to be shared .. and maybe code.


A patch relative to SDB 1.3.4 or the development code tree would be easier to process although the differences (IIRC) aren't huge.

        Andy

Reply via email to