Hello there !
It seems to me that there is a storage problem, when you create a lot of nodes,
one by one, using this algorithm :
1. for each node to create
a. create node
b. fill node properties/child nodes
c. save session
2. end for
The
++;
session.save();
}
/
// END SECOND ALGORITHM //
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : Thomas Mueller [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 20 juin 2007
= contractors.addNode(lgw:contractor);
initializeContractor(session, contractor);
created++;
session.save();
}
/
// END SECOND ALGORITHM //
Frédéric Esnault - Ingénieur RD
creation then save strategy. But in production,
users are definitely going to use the one by one creation/saving strategy,
which scares me
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Felix Meschberger
Envoyé
As you can see, the tree structure gives this :
/
|-lgw:root
|-lgw:contacts
|-lgw:contact
|-lgw:contact
...
You can replace contractor(s) by contact(s) in the code
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : Thomas Mueller [mailto:[EMAIL PROTECTED]
Envoyé
:[EMAIL PROTECTED]:manager='Frederic Esnault']
Creating deeper hierarchy is a possibility but would increase persistence
services complexity.
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : Thomas Mueller [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 20 juin 2007 11:56
À : dev
Just a question, is the 1.4 Jackrabbit mandatory or can I replace by a
dependency to 1.3 ?
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : Thomas Mueller [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 20 juin 2007 11:56
À : dev@jackrabbit.apache.org
Objet : Re: atomic vs group
Hi all,
I encountered a problem working with a SQL request :
SELECT lgw:contractorType.lgw:title FROM lgw:contractorType, lgw:contractType
WHERE lgw:contractType.jcr:uuid= 'b744b41b-8425-4008-99a6-ce8456d87c4e'
AND lgw:contractorType.jcr:uuid=lgw:contractType.lgw:internalContractor
Just a correction, the NullPointerException is raised by : literal.getValue();
It seems the query is correctly parsed, it gets the identifiers, but seems to
use the literal code (restriction) for identifier comparison (join).
Any idea ?
Frédéric Esnault - Ingénieur RD
-Message d'origine
Don't tell me it's because of spec, section 8.5.2.6 about joins, only on
primary node type and mixin node type tables and on jcr:path propertyPlease
!
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : Frédéric Esnault [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 20 juin 2007
?
And subsidiary question : I read here once that because of shared abstract
query language, something done for xpath must be done for sql also. Isn't there
a jcr:deref equivalent in sql?
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : Jukka Zitting [mailto:[EMAIL PROTECTED
leaving, and see if it
helps.
Frédéric Esnault - Ingénieur RD
-Message d'origine-
De : siraj ahmed [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 20 juin 2007 14:08
À : dev@jackrabbit.apache.org
Objet : exception
I am getting this problem when ever I restart my application , any
solution
Hi there !
I've been thinking about what I've been told here.
It has been said that :
- Jackrabbit doesn't like same name siblings, so it would be better to
give nodes specific names;
- Jackrabbit doesn't like too many child nodes under on same nodes
(ie. 1000 or more
Hi there,
I saw something vry interesting in jackrabbit wiki : Indexing Configuration.
Actually it may be a way to tune up the index and allow some searches that
today are very slow. It is definitely a good point to be able
to adapt jackrabbit indices to one's particular repository
For example, consider a node /A with 5 children named B. You would access
the first as /A/B[0] the second as /A/B[1] and so forth. If you now decide
to delete the second one (B[1]) the indices of all same name siblings whose
index is larger than 1 will change. So B[2] becomes B[1], B[3]
it's not that Jackrabbit doesn't like it, it's because samename
siblings cause a lot of issues from a user perspective (e.g. the path
'/a/b[2]' is not stable since it might become
'/a/b[1]' if '/a/b[1]' were removed).
Yes, but as i answered before, the spec only says that the order of same
Frédéric Esnault - Ingénieur RD
i tested write performance (adding a node to a parent with many child nodes)
since this suffers with very large child node sets. using samename siblings
has
no impact on write performance.
Writing one node, even with thousands of child nodes already
So far I couldn't reproduce the problem. The size (280 MB) could have
another reason, maybe the database does not re-use empty space for
some reason. When I had a similar problem, I also had a really large
database (about 1 GB), but after compressing it was only 10 MB or so.
It was not
is not a good idea, this is exactly what I'm trying
to evaluate currently, but for this I have to push Jackrabbit to its limits and
see how good (or bad) it reacts to our requirements.
Frédéric Esnault
Hi Thomas, thanx for your test tool.
I modified it to include the CNDs, the business roots, and the real random data
generator, and I'm afraid I cannot reproduce the problem.
Here is my output :
*** Initializing repository ***
Initializing repository
[{http://www.legisway.com}addressType]
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
À : dev@jackrabbit.apache.org
Objet : Re: atomic vs group node creation/storage
Hi,
The number of rows
, and why this external tool does only
creating 2 500 child nodes.
In fact my webapp is configured in maven, with jackrabbit 1.3 as a dependency.
For this tool, I quickly copied jars of Jackrabbit 1.2.3. Shame on me ;-)
Frédéric Esnault
-Message d'origine-
De : Stefan Guggisberg [mailto
)
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
version_binval: 0
SELECT COUNT(*) FROM version_node: 1
SELECT COUNT(*) FROM version_prop: 1
SELECT COUNT(*) FROM version_refs: 0
Frédéric Esnault
-Message d'origine-
De : Thomas Mueller [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 21 juin 2007 15:56
À : dev@jackrabbit.apache.org
Objet : Re
Hi all !
I'm facing a strange situation. I'm wondering if I'm doing something wrong or
if it's a jackrabbit problem.
I tried this search : /jcr:root/lgw:root/lgw:contracts/element(*,
lgw:contractType)[jcr:deref(@lgw:internalContractor,
'lgw:contractorType')/@lgw:companyName = 'Lycos']
(@lgw:internalContractor,
'lgw:contractorType')/@lgw:companyName = 'Lycos']
Is there antoher way to make this query?
Frédéric Esnault - Ingénieur RD
Legisway
60 boulevard de la mission Marchand
92400 Courbevoie La Défense
-Message d'origine-
De : Marcel Reutegger [mailto:[EMAIL PROTECTED]
Envoyé
Thanks for the answer, but my question was : is there another way only using
XPath? I should have been clearer, sorry.
Frédéric Esnault
-Message d'origine-
De : Marcel Reutegger [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 22 juin 2007 12:28
À : dev@jackrabbit.apache.org
Objet : Re
?
Frédéric Esnault
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Bertrand
Delacretaz
Envoyé : vendredi 29 juin 2007 13:09
À : dev@jackrabbit.apache.org
Objet : Re: Jackrabbit press release
On 6/29/07, Frédéric Esnault [EMAIL PROTECTED] wrote:
...About
-Message d'origine-
De : Jukka Zitting [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 29 juin 2007 13:30
À : dev@jackrabbit.apache.org
Objet : Re: Jackrabbit press release
Personally I find milestones in this process to be
much more interesting and newsworthy than reaching a plateau where
!
Frédéric Esnault
Thank you very much, Stefan !
Frédéric Esnault
-Message d'origine-
De : Stefan Guggisberg [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 4 juillet 2007 15:56
À : dev@jackrabbit.apache.org
Objet : Re: CND ignore
hi frederic,
On 7/4/07, Frédéric Esnault [EMAIL PROTECTED] wrote:
Hi all
31 matches
Mail list logo
