Hi Stefan and thanks for the explanations!
There is no panic, but everybody should be able to understand this before going
into production :-).
I guess this is very good knowledge for everybody:
[quote]
30k child nodes to one single node per normal blob entry. If you think that your structure will
overpass this number (which is completely unrecommended) you can customize the blob size (at least
with MySQL, Derby)
[/quote]
./alex
--
.w( the_mindstorm )p.
#: Stefan Guggisberg changed the world a bit at a time by saying (astral date:
4/20/2006 12:02 PM) :#
don't panic, folks! ;)
the default schema for derby uses a 'blob' column for storing the
serialized node states. as brian pointed out correctly, the blob
column has a max. size of 1mb if no size has been specified.
i ran a quick test: i was able to add ~37k child nodes before hitting
the 1mb size limit. i think that this is perfectly reasonable and
i guess that most repositories won't ever come near this limit.
however, if you really think that you need to be able to add more
than ~30k child nodes to one single node you could easily change
your schema, e.g. by specifying 'blob(5M)' as the data type of
the NODE_DATA column..
again: i would stronlgy discourage from this kind of 'flat' repository
model unless you have a very compelling reason. jcr's data model is
inherently hierarchical so i'd suggest to better make use of this powerfull
feature.
cheers
stefan
On 4/19/06, Brian Moseley <[EMAIL PROTECTED]> wrote:
On 4/19/06, Martin Perez <[EMAIL PROTECTED]> wrote:
> I have no problems uploading various megabyte files to derby without
> configuring anything...
that's not the issue. saving serialized node states with
DerbyPersistenceManager is what we're talking about.
