12 Jun
2010
12 Jun
'10
6:55 a.m.
Ivan Levashew wrote:
I have seen another threads, but I didn't noticed
any good idea. I have
only seen JCR project in the sandbox.
http://dev.xwiki.org/xwiki/bin/view/Design/JcrStore
I have no idea what is JCR. «JCR» sounds very different from
«filesystem». Installing and maintaining JCR is likely to be yet another
brainache I'd like to skip. Finally, «Translate XWQL to JCRSQL2» sounds
very different from «simple and reliable».
JCR seems to be proposed as a
replacement for the database entirely.
I would have to see it's performance before I would want to advocate for the idea.
«Storing 10Mb octet streams
in database» doesn't sound like being reliable, and indeed it caused
strange problems recently.
On the one hand it definitely over-stresses the database
but on the other hand
it is very nice to be able to do a database dump, wipe the disk, load the dump
and be right back where you were before. Maybe a hybrid where content is stored
in the db and 'cached' on the hard disk but caches make debugging a huge pain.
Still something has to be done about the max_packet issue.
So my humble wish is to see xwikiattachment_content table replaced with
a mere filesystem storage. Other tables left intact. Maintaing
«Space/Document/Attachment» structure is not a requirement (althoung it
would be nice since I could share it in GreyLink DC++ this way).