29 Mar
2008
29 Mar
'08
6:13 p.m.
Hi guys,
As I understand from the archive, attachments are stored in the DB itself,
is that correct?
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?
Thanks!
29 Mar
29 Mar
10:48 p.m.
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#a11…
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
11:55 p.m.
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
Thanks for that, Ricardo!
31 Mar
31 Mar
12:02 a.m.
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?
12:52 a.m.
Squirrel wrote:
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?
I am afraid I must also raise my hand, even both hands!, again and
again
looking for help to understand the whole thing! :-) I am far from being
able to answer your question on a solid basis, but read this extracted
from Jackrabbit FAQ at
http://jackrabbit.apache.org/frequently-asked-questions.html ...
*****
*What is a Jackrabbit file system?*
A Jackrabbbit file system (FS) is an internal component that implements
standard file system operations on top of some underlying storage
mechanism (a normal file system, a database, a webdav server, or a
custom file format). A file system component is any Java class that
implements the FileSystem interface and the associated behavioral
contracts. File systems are used in Jackrabbit both as subcomponents of
the persistence managers and for general storage needs (for example to
store the full text indexes).
*****
So, it seems to me that Jackrabbit is a kind of overall layer that
doesn't mind what in the hell it has under it. And a "normal" file
system is one of the options. So, I guess any application running now on
XWiki will keep working, or must keep running, it this or any other
content stored is adopted to held future XWiki development.
By the way, are you following xwiki-devs? See this...
http://www.nabble.com/XWiki--Dev-f2564.html
And Jira Issues are also of great help trying to understand what is
going on within XWiki. Just in case you have not gone there yet...
http://jira.xwiki.org
As far as I can perceive, this is a hot topic in XWiki.
HTH,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
9 Apr
9 Apr
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?
6063
days inactive
6074
days old
5 comments
3 participants
participants (3)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
Sergiu Dumitriu -
Squirrel