jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: atomic vs group node creation/storage
Date Thu, 21 Jun 2007 13:56:19 GMT
Hi,

How does this table look like?

show columns from default_node;
Field  	Type
NODE_ID	char(36)
NODE_DATA mediumblob

Maybe this is different in your environment.
Thomas

On 6/21/07, Frédéric Esnault <fesn@legisway.com> wrote:
> Now I have a strange problem with the test tool. I tried to launch creation on 2500 nodes,
and got this :
> Exception in thread "main" javax.jcr.RepositoryException: /: unable to update it
> em.: failed to write node state: 409d58ab-bd92-410c-8096-1fca52b8ef63: failed to
>  write node state: 409d58ab-bd92-410c-8096-1fca52b8ef63
>         at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1212)
>         at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:823)
>         at TestSingleGroup.testOneByOne(TestSingleGroup.java:109)
>
> Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long fo
> r column 'NODE_DATA' at row 1
>
>
> Frédéric Esnault
>
> -----Message d'origine-----
> De: Thomas Mueller [mailto:thomas.tom.mueller@gmail.com]
> Envoyé: jeudi 21 juin 2007 11:25
> À: dev@jackrabbit.apache.org
> Objet: Re: atomic vs group node creation/storage
>
> Hi,
>
> > The number of rows was increasing also very fast.
> > When my default_node table reached 22 GB, it was holding 35 million rows.
>
> Is the problem now, that it is reproducible on your machine, but not
> on my machine? Could you run my test case on your machine? It is
> simpler and doesn't use node types. If you can't reproduce the problem
> with my test on your machine, but can reproduce it with your test
> case, could you send your complete test code (there are still some
> pieces missing, for example initializeContractor)?
>
> > The problem here is that if you use predicate on the node with plenty of instances
(say a contract), the search works fine,
>
> OK
>
> > the problem is if the search has to look at all the instances of this type of node.
>
> I'm not sure if I understand the problem... You would search all nodes
> of the same type without any condition ("SELECT * FROM x:y")? Why
> would you do a search like this, and how would using same name
> siblings solve the problem?
>
> > We actually plan a 100K nodes repository, with an extreme limit to 250K,
> > which could possibly mean something like a maximum of 25K to 30K child nodes,
>
> Somebody else already said, many child nodes is only a problem for
> writing. And for manually browsing the repository, if you want to do
> that.
>
> Thomas
>
> Attachment: testSingleGroup.zip (I hope this works)
>

Mime
View raw message