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:[email protected]] > Sent: Saturday, March 14, 2009 1:37 PM > To: [email protected] > Subject: Re: Jackrabbit fails to start if database user is not schema > owner > > On Fri, Mar 13, 2009 at 10:35 AM, Stefan Guggisberg > <[email protected]> wrote: > > On Fri, Mar 13, 2009 at 10:28 AM, Jukka Zitting > <[email protected]> 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 > [email protected]
