Hi, +1 for JIRA issue.
As it's not strictly a bug, I would say it's an "enhancement". Regards, Thomas On Wed, Mar 18, 2009 at 9:48 AM, Martijn Hendriks <[email protected]> wrote: > 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] >
