On Tue, May 6, 2008 at 11:56 AM, amsmota <[EMAIL PROTECTED]> wrote: > > I notice that if I have different schemaObjectPrefix for > > A) Repository/FileSystem -> 1 table > B) Repository/Workspace/FileSystem -> 1 table > C) Repository/Workspace/PersistenceManager -> 4 tables > D) Repository/Versioning/FileSystem -> 1 table > E) Repository/Versioning/PersistenceManager -> 4 tables > > A, B, D -> *fsentry > C, E -> *binval, *node, *prop, *refs > > I end up with 11 tables. If I use a common schemaObjectPrefix (or if I use > the schemaObjectPrefix to configure my schema, see > http://www.nabble.com/Using-diferent-database-schemas-td16993168.html here ) > I only get 5 tables. > > Now what I want top know is what was the rationale behind the implementation > of this (optionally) different schemaObjectPrefix's. Is just a question of > housekeeping, to properly identify the different types of repository, to > prevent the tables getting to big? Or is there a more "profound" reason?
every DatabaseFileSystem and DatabasePersistenceManager instance that uses a shared db absolutely *needs* to specify a unique schemaObjectPrefix value. failing to do so will most probably lead to data corruption. an example: api-level locks are currently persisted in the workspace FileSystem. multiple wokspaces using identical schemaObjectPefix values could therefore potentially overwrite/corrupt each others locks files. cheers stefan > > I need to know this to go ahead with the use of schemaObjectPrefix to define > my database schema or not. > > Thanks all. > > > > > -- > View this message in context: > http://www.nabble.com/Use-of-diferent-or-same-schemaObjectPrefixes-tp17079492p17079492.html > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >
