Open Source Document Management System | OpenKM

I\'ve been evaluating OpenKM for use as a DMS. A few days ago, I configured it to use MySQL but had a question about the repository.xml file. In repository.xml I\'ve noted three areas that define FileSystem

/Repository/FileSystem
/Repository/Workspaces/FileSystem
/Repository/Versioning/FileSystem

I\'ve been unable to find documentation that discusses how these three differ. The JDBC Example for Oracle only modifies Workspaces and Versioning portions of the repository. I used that as my template for MySQL and it appears to be using MySQL, as I can see tables and records have been created.

However why doesn\'t the Oracle example modify /Repository/FileSystem? Basically, I\'m trying to determine what\'s getting written to my MySQL database and what isn\'t, and what I\'d need to do for backups. I can tell both the file system and the database are increasing in size.

Thanks for your time.


Adam

The best configuration is what is set by default in OpenKM when you have downloaded from sourceforge. You can change hypersonic - embeded database - to mysql is good option.

OpenKM has tree data information:
blobs -> by default in file system
indexed data by lucene -> by default in file system
repository structure -> by default in database

For better performance is better have documents ( blobs ) directly on file system, because if you use a database for it purpose you lose some time on each downloading call for example, when database puts document from database to temporary directory on server and after it jboss offers this document to end users, you lose here database time, it\'s better if you\'ve got file - blob - directly in your file system.

Hope it could help you, deciding where to define a database pool and where not.

Thanks for the response.

From the standpoint of using the built-in verses a third party DB, I\'m weighing the ability to mirror the repository to an offsite location, for Disaster Recovery purposes. This would be fairly simple to do with MySQL replication, however it might require a bit more work with file based synchronization. I\'d only require asynchronous updates and am still just looking into how OpenKM functions.

I\'ve been monitoring the local disk updates a bit more closely and have noted that growth has primarily been the index changes. I\'m going under the assumption the default/db/log and default/db/segments also pertain to the indexes. The majority of growth has been in the database.


Adam