9 Apr
2008
9 Apr
'08
7:03 p.m.
Squirrel wrote:
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/
On Sat, Mar
29, 2008 at 4:48 PM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> 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#a11…
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?