Hi! I am wondering how this customization of the DDL should be done... I must go in the jar and modify the DDL in there? Or is it a way to externalize it?
many thanks in advance, ./alex -- .w( the_mindstorm )p. On 4/20/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > 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. > >> > > > >
