In our environment, we are only working with derby/DB2/SQLServer/Oracle. I hope it won't be too much work to get it right in other databases since the syntax is mostly schema.table. I didn't know that database.schema.table was an option (and it could complicate things). More generally, because of the weak abstraction over table names, it may take some work to adjust the patch to accommodate other syntaxes. However, if certain DBs don't support schemas well, we could simply disallow the use of this feature for them, given that it is an optional setting.
In any case, if we internally decide to go forward with SDB, we will probably end up contributing this, but if we don't adopt, I doubt I will be able to contribute it. And I must say that our current performance measurements for graph insertion/update are not encouraging. If there are any tricks I should be aware of, please let me know thanks, Simon From: Andy Seaborne <[email protected]> To: [email protected] Date: 06/02/2011 06:39 AM Subject: Re: SDB and schemas 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
