jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Hendriks <marti...@gx.nl>
Subject RE: Jackrabbit fails to start if database user is not schema owner
Date Wed, 18 Mar 2009 08:48:41 GMT
Hi,

Sorry for the late reply... I checked again and figure that it is not really about permissions
but about calling the DatabaseMetaData#getTables method with the right schemaPattern. If the
user from the repository.xml is used, then the table is not found (yet that user can manipulate
date), but if the schemaowner user is used, it works fine. 

Disabeling the checkschema method as Alexander suggests would solve this. It can be done by
a system property or by an additonal configuration entry in the repository.xml. Is it ok if
I create a JIRA issue for this?

Best regards,
Martijn

> -----Original Message-----
> From: Alexander Klimetschek [mailto:aklimets@day.com]
> Sent: Saturday, March 14, 2009 1:37 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: Jackrabbit fails to start if database user is not schema
> owner
> 
> On Fri, Mar 13, 2009 at 10:35 AM, Stefan Guggisberg
> <stefan.guggisberg@gmail.com> wrote:
> > On Fri, Mar 13, 2009 at 10:28 AM, Jukka Zitting
> <jukka.zitting@gmail.com> wrote:
> >> Hi,
> >>
> >> Thinking out loud: Wouldn't it be so simple if a database-based
> >> persistence manager used only a single table with the workspace name
> >> included as an extra column?
> >
> > agreed, however write performance might suffer in the case of many
> large
> > workspaces.
> 
> It probably only "really" suffers when multiple workspaces are used at
> the same time, forcing the database to synchronize stuff that is
> actually separate.
> 
> But a simpler solution for the problem that a user might have rights
> to read/write a table, but not rights to see the metadata about it (if
> this is actually possible in some databases), would be to add an
> option for disabling the checkSchema() check. This would not read the
> metadata to check for existence of the table and would not try to
> create a table. Instead it could simply log the necessary create table
> sql statement (eg. if an sql error happens, like "table does not
> exist").
> 
> This option would be off by default and wouldn't force us to rewrite
> all the persistence managers and break backwards compatibility.
> 
> Regards,
> Alex
> 
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

Mime
View raw message