Hi Squirrel, Squirrel wrote:

Hi guys,

As I understand from the archive, attachments are stored in the DB itself, is that correct?

Yeap.

That's not very handy for my personal use. I have written an automated backup bash-script, which dumps all DB's from my MySQL-installation into a backup folder and store it there (a daily folder with the last 7 dumps, a weekly folder and a monthly) and pushes once a night the backup folder to a backup-server. Now if every attachment is stored into the DB, the DB will grow extensively (versioning?, picture album), while with an ordinary file-store system you just backup files, who have changed or are new....in my use scenario, attachments are way more stable than the actual content in the XWiki...

Out of curiosity, what's exactly the benefit to store files in a DB? For the XWiki, is that the way you go or are you planning to implement a choice?

Well, obviously I am not a XWiki guru, but it seems to me that it was, and in fact it is, a good idea to have a single access control system. If you have the whole system in a database, you have not to be concerned about how to control access to other repositories. And at at the same time, to have the whole thing in a single database gives, at least to me, an feeling of full control about what is going on with the contents I've to manage. Other idea: you easy can index and search the whole content with a single search engine. And control access to the results! But, as you says, there are a number of problems with this approach. I am sure this thread will be useful for you... http://www.nabble.com/Xwiki-file-and-attachment-storage-td11991466.html#a119... And as a last minute entry, see this... http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebDAVApi2008 Hope this helps, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

On Sat, Mar 29, 2008 at 4:48 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote: Well, obviously I am not a XWiki guru, but it seems to me that it was, and in fact it is, a good idea to have a single access control system. If you have the whole system in a database, you have not to be concerned about how to control access to other repositories. And at at the same time, to have the whole thing in a single database gives, at least to me, an feeling of full control about what is going on with the contents I've to manage. Other idea: you easy can index and search the whole content with a single search engine. And control access to the results!

But, as you says, there are a number of problems with this approach.

I am sure this thread will be useful for you...

http://www.nabble.com/Xwiki-file-and-attachment-storage-td11991466.html#a119...

And as a last minute entry, see this...

http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebDAVApi2008

Hope this helps,

Ricardo

Pardon me to raise my hand again, but I still don't get it after reading it over and over again. This JackRabbit-Implementation, will it allow to store files in the file-system rather than in the DB? What about, ie., the photo-album feature, will it still work when the fotos are stored in the file-system?

Squirrel wrote:

...

On Sat, Mar 29, 2008 at 4:48 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote: Well, obviously I am not a XWiki guru, but it seems to me that it was, and in fact it is, a good idea to have a single access control system. If you have the whole system in a database, you have not to be concerned about how to control access to other repositories. And at at the same time, to have the whole thing in a single database gives, at least to me, an feeling of full control about what is going on with the contents I've to manage. Other idea: you easy can index and search the whole content with a single search engine. And control access to the results!

But, as you says, there are a number of problems with this approach.

I am sure this thread will be useful for you...

http://www.nabble.com/Xwiki-file-and-attachment-storage-td11991466.html#a119...

And as a last minute entry, see this...

http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebDAVApi2008

Hope this helps,

Ricardo

Pardon me to raise my hand again, but I still don't get it after reading it over and over again. This JackRabbit-Implementation, will it allow to store files in the file-system rather than in the DB? What about, ie., the photo-album feature, will it still work when the fotos are stored in the file-system?

The storage consists of several interfaces, like XWikiStoreInterface, XWikiAttachmentStoreInterface, XWikiVersioningStoreInterface and others. The data model is an abstract data structure that can be accessed, and where exactly it is stored is of no importance. The storage interfaces can have any implementation, it could even be a plain filesystem storage (though it would be hard to do search that way...). Now, the JCR storage adds an extra abstraction layer. It is meant to be a generic storage interface which can have many implementations, and it actually does have those implementations. The advantage of using JCR is that we're dropping the implementation concern to a third party, instead of having to write it ourselves. JCR can be configured to use the filesystem as the storage component, so, up the library chain, the attachments will be: - stored on the filesystem (JCR storage implementation) - transparently transformed to a storage service available using a JCR API (JCR core) - retrieved from there... (XWiki Storage Interface) - ...and transformed into a data model object (XWikiAttachment) - and then used however you want in the core, web, or document content So, given the abstraction layer behind the data model, anything should work as normal regardless of where are attachments really stored. -- Sergiu Dumitriu http://purl.org/net/sergiu/