I submitted the following as a bug about two weeks ago, but perhaps that
wasn't the right way to ask for help about this problem, so I'm trying the
list --
I tried both 1.3 M2 and 1.2.2, and I had the following problem (both using
the standalone zip version on Windows) :
If you create a table on
; This is really necessary for scalable deployment.
>>
>> And BTW there is no max_packet_size restriction as well.
>>
>> One can also do streaming with db BLOBs, but not via hibernate I
>> believe.
>>
>> -Original Message-
>> From: [EMAIL
vmassol wrote:
>
> However I'm curious to know why you need attachments stored in the
> file system.
>
Because many of these attachments may be large (>50MB), and over time the
database can grow to be unweildy. Currently that's our problem with our
exchange server setup (people keep emailin
>> Is that what you mean? And is this Jackrabbit
>> stuff ready by v1.1?
>Nope. This is 1.2 stuff.
Well, 1.2 is almost here... is the jackrabbit stuff ready, and can I store
attachments in files??
--
View this message in context:
http://www.nabble.com/Xwiki-file-and-attachment-storage-tf421
http://jackrabbit.apache.org/faq.html#whats-fs wrote:
>
> 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 webda
vmassol wrote:
>
> Google is your friend... :)
>
> For example, at random:
> http://www.onjava.com/pub/a/onjava/2006/10/04/what-is-java-content-
> repository.html
>
> -Vincent
>
>
Sure, Google is my friend. :)
What I was wanting to know, though, is whether the work you're doing will
imp
vmassol wrote:
>
> Artem, would you mind giving us a status on the JCR work and the plan
> ahead?
>
vmassol wrote:
>
>> So I take it nothing like this is in the works? :)
>
> like what? (did you see my answer btw)
>
Just the part about storing attachments as files outside of the DB.
Esbach, Brandon wrote:
>
>>>With a little work, you could probably intercept the upload via
> groovy, place it on a network drive, replace the attachment with a link
> to that network file..
>
> Would think that this would be your next step? Granted, I've never
> tested the idea; but it shoul
Esbach, Brandon wrote:
>
> So far my own internal wiki's run at between 5mb and 3gb -
> with no real noticable difference in performance from the smallest to
> the largest.
>
Hmmm, yes, the problem seems to be currently that our Exchange database
right now is 200gb, filled mostly with all the
