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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Envoyé: jeudi 21 juin 2007 11:25
À: [email protected]
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)
