Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of shelsen@ca.ibm.com designates
 32.97.182.137 as permitted sender)
In-Reply-To: <4DE767ED.40800@epimorphics.com>
References: 
 <OF4036FC10.F325999D-ON852578A2.0052B079-852578A2.0053D218@ca.ibm.com>
 <4DE767ED.40800@epimorphics.com>
To: jena-dev@incubator.apache.org
MIME-Version: 1.0
Subject: Re: SDB and schemas
Message-ID: 
 <OF6D265D2A.DFB0711B-ON852578A3.004829E9-852578A3.0048CD0A@ca.ibm.com>
From: Simon Helsen <shelsen@ca.ibm.com>
Date: Thu, 2 Jun 2011 09:15:09 -0400
Content-Type: multipart/alternative;
 boundary="=_alternative 0048CD0A852578A3_="

--=_alternative 0048CD0A852578A3_=
Content-Type: text/plain; charset="US-ASCII"

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 <andy.seaborne@epimorphics.com>
To:
jena-dev@incubator.apache.org
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 (shelsen@ca.ibm.com)

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


--=_alternative 0048CD0A852578A3_=--