Thansk for your answer Thomas, but I found my answer already and Stefan confirmed ;)
By the way now it's a mediumblob, but I changed the jackrabbit jars to 1.3 and relaunched the 2500 test, so repository tables have been recreated (still running, until now, everything runs fine....) Frédéric Esnault -----Message d'origine----- De : Thomas Mueller [mailto:[EMAIL PROTECTED] Envoyé : jeudi 21 juin 2007 15:56 À : [email protected] Objet : Re: atomic vs group node creation/storage 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) >
