incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Helsen <>
Subject Re: SDB and schemas
Date Thu, 02 Jun 2011 13:15:09 GMT
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



Andy Seaborne <>
06/02/2011 06:39 AM
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 
> 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 
> is used to create tables. At the same time, some db commands 
> 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 (

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message