On Jun 12, 2010, at 6:55 AM, Caleb James DeLisle wrote: > > > 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.
This is not correct. JCR is simply a Java API and an SPI for implementers to plug any storage. There are SPI implementations for filesystem, RDBMS, and more. If you prefer it serves a similar purpose as Hibernate but in a standard way and more generic since it supports any type of storage. See http://en.wikipedia.org/wiki/Content_repository_API_for_Java for example. > I would have to see it's performance before I would want to advocate for the > idea. The only potential problem re performance is the mapping between the java objects and the tables if you choose the RDBMS SPI. We'll need to compare the performance with our current Hibernate solution indeed. >> «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). Actually we have a separate Attachment storage (there's an interface called XWikiAttachmentStoreInterface) and it should be pretty easy to implement a file-based implementation of it. I wonder why nobody has done it before.... Thanks -Vincent _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
