Hi Marcel,
On 21/08/07, Marcel May <[EMAIL PROTECTED]> wrote:
> Jackrabbit must support JTA if it wants to support TXs according to the
> JCR Spec
> (see previous discussion,
> http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06525.html).
> At the moment, this is a spec violation IMO: JR s
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1073:
-
Attachment: patch.txt
A first shot how this might look like. I stumbled over QueryResultImpl which
Add getTotalSize() to QueryResults
--
Key: JCR-1073
URL: https://issues.apache.org/jira/browse/JCR-1073
Project: Jackrabbit
Issue Type: New Feature
Components: query
Reporter: Christoph K
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch_with_extendible_system_nodetypes.txt
I'm not really happy with all those solution
Ard Schrijvers wrote:
Wellif I start implementing the 1:1 mapping simultaneously and have to
make this backwards compatible also for old indices, I am afraid that I have
to test all around the place.
As far as I can see the following needs to be done:
In LuceneQueryBuilder methods need t
Ard Schrijvers wrote:
Christoph Kiehl wrote:
4. Regarding sorting: We will still need our own sorting because we cache
the document order per subreader whereas lucenes sorting only caches per
reader which get invalidated after every write operation. But the initial
cache creation will be faster.
>
> Marcel Reutegger wrote:
> > Christoph Kiehl wrote:
> >> Marcel Reutegger wrote:
> >>
> >>> 1) New QueryHandler class
> >>> 2) Introduce parameter in configuration
> >>> 3) Auto-detect in SearchIndex
>
> [...]
>
> > ok, I'm at a point where I think we should implement 3). I
> don't have
>
> Christoph Kiehl wrote:
> In general I think it's a good idea to have a 1:1 mapping of
> properties to
> lucene fields. It's just more natural and easier to
> understand as you said.
>
> Performance wise I'm not sure if it will gain you "lots of
> performance". I just
> had a quick look at
[
https://issues.apache.org/jira/browse/JCR-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved JCR-1068.
-
Resolution: Fixed
Fixed with revision 568259.
> NamespaceRegistryTest.testRegisterNamespace test
[
https://issues.apache.org/jira/browse/JCR-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521570
]
Julian Reschke commented on JCR-1068:
-
Modified proposal: when creating a child node fails, try a property instead.
[
https://issues.apache.org/jira/browse/JCR-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521568
]
Bertrand Delacretaz commented on JCR-701:
-
The Xerces dependency might still be needed for JCR-19
> Upgrade to
[
https://issues.apache.org/jira/browse/JCR-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned JCR-1068:
---
Assignee: Julian Reschke
> NamespaceRegistryTest.testRegisterNamespace test assumptions
> -
[
https://issues.apache.org/jira/browse/JCR-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521564
]
Jukka Zitting commented on JCR-701:
---
> I'm not really sure why we have a dependency on Xerces at all.
The dependency
Marcel Reutegger wrote:
Christoph Kiehl wrote:
Marcel Reutegger wrote:
1) New QueryHandler class
2) Introduce parameter in configuration
3) Auto-detect in SearchIndex
[...]
ok, I'm at a point where I think we should implement 3). I don't have
fundamental opposition against it and you think
[
https://issues.apache.org/jira/browse/JCR-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521562
]
Julian Reschke commented on JCR-701:
Hm.
I'm not really sure why we have a dependency on Xerces at all. The JDKs sh
Ard Schrijvers wrote:
So, WDOT about indexing properties in seperate lucene Fields, and about
possibly indexing more information of one property. My experience with
lucene, is that indexing tactically, eases querying a lot, and gains you lots
of performance. So, if you do agree on these changes,
Padraic Hannon wrote:
> I concur, relational semantics should be buried within the persistence
> managers. However, I think that one can still delegate transaction
> handling using JTA to the container rather than using synchronization
> and connection.autocommit(false).
Jackrabbit must support JT
I concur, relational semantics should be buried within the persistence
managers. However, I think that one can still delegate transaction
handling using JTA to the container rather than using synchronization
and connection.autocommit(false). Obviously this should be configurable.
Regardless of
Weblogic and oracle do something similair as well. Also, the PreparedStatement caches in those pools are configurable. Once I have the chance, hopefully this week, I'll get some testing done with the code I modified. Also, Derby has a pooled connection system as well.
-pih
Thomas Mueller wrote
SPI-commons: QValueTest.testDateValueEquality2 fails due to changes made with
JCR-1018
---
Key: JCR-1072
URL: https://issues.apache.org/jira/browse/JCR-1072
Project:
Hi,
> returns a prepared statement back to a pool (instead of really closing it)
You are right, that's great!
Then we should test if the PooledConnectionPersistenceManager really
does improve the performance, and in what cases.
Thomas
PROPPATCH on collection gets 403 Forbidden
--
Key: JCR-1071
URL: https://issues.apache.org/jira/browse/JCR-1071
Project: Jackrabbit
Issue Type: Bug
Components: webdav
Affects Versions: 1.
Hi,
On 8/21/07, Thomas Mueller <[EMAIL PROTECTED]> wrote:
> > Any reasonable connection pool will pool also the prepared statements,
>
> I would not be so sure. Maybe if you don't close the prepared
> statement (not sure about the disadvantages of that). In any case it
> needs to be tested.
At le
> PreparedStatement ps = connection.prepareStatement(...);
> try {
> // use the prepared statement
> } finally {
> ps.close();
> }
> Any reasonable connection pool will pool also the prepared statements,
I would not b
Hi,
On 8/21/07, Thomas Mueller <[EMAIL PROTECTED]> wrote:
> Reusing prepared statements is harder with pooled connections. In JDK
> 1.6, thanks to javax.sql.StatementEventListener, they can if the
> connection pool manager supports it. In JDK 1.4 and 1.5, I am not sure
> what / when connection poo
> On 8/21/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
>
> > ...
> > value="org.apache.lucene.analysis.fr.FrenchAnalyzer"/>
> > value="org.apache.lucene.analysis.de.GermanAnalyzer"/>
> >
> >
> >
> > bode_fr
> >bode_de
> > ...
>
> I prefer this variant, where
[
https://issues.apache.org/jira/browse/JCR-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521457
]
angela commented on JCR-1070:
-
> My only wish about structure is that we get rid of the subproject...
sure. that's what i
[
https://issues.apache.org/jira/browse/JCR-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521453
]
Jukka Zitting commented on JCR-1070:
+1 Feel free to go forward!
My only wish about structure is that we get rid o
On 8/21/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
> ...
> value="org.apache.lucene.analysis.fr.FrenchAnalyzer"/>
> value="org.apache.lucene.analysis.de.GermanAnalyzer"/>
>
>
>
> bode_fr
>bode_de
> ...
I prefer this variant, where you define reusable analyz
> Ard Schrijvers wrote:
> >
> > value="org.apache.lucene.analysis.fr.FrenchAnalyzer"/>
> > value="org.apache.lucene.analysis.de.GermanAnalyzer"/>
> >
> >
> >
> > bode_fr
> >bode_de
> >
> Marcel Reutegger wrote:
> I like this one.
Should I wait with a JIRA issue to see
Ard Schrijvers wrote:
bode_fr
bode_de
I like this one.
regards
marcel
> A single DB connection can only process a single operation at a time.
> Jackrabbit locks up completely while storing (example: a larger
binary)
> - not only for reading but also for writing.
> There has been some improvements AFAIK, but it still applies for write
> operations.
> A simple insert o
Sorry, I accidentely sent the mail while not finished:
> Ok. If others agree, I will create a JIRA improvement issue
> for it. I be able to implement it. When succeeded, I can add
> documentation. The only thing I would need feedback on is how
> people would like to see it in the index_configur
> Marcel Reutegger wrote:
> sounds good. We just have to document the limitations properly.
Ok. If others agree, I will create a JIRA improvement issue for it. I be able
to implement it. When succeeded, I can add documentation. The only thing I
would need feedback on is how people would like to
> Ard Schrijvers wrote:
> > So, WDOT about indexing properties in seperate lucene
> Fields, and about
> > possibly indexing more information of one property.
>
> Marcel Reutegger wrote:
> Because the number of distinct property names in jackrabbit
> is unlimited (think
> of nt:unstructured node
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521417
]
Marcel Reutegger commented on JCR-1066:
---
There's another potential issue. I know of at least one implementation t
Ard Schrijvers wrote:
Now, Marcel correctly pointed about the problem when referring to the node
scope search:
//*[jcr:contains(., 'hägar')]
As I have given it another thought, it does make sense to me, that when
searching in the node scope, you use the global/default analyzer, and when
you are
Ard Schrijvers wrote:
So, WDOT about indexing properties in seperate lucene Fields, and about
possibly indexing more information of one property.
Because the number of distinct property names in jackrabbit is unlimited (think
of nt:unstructured nodes), this would lead to a great number of file
[
https://issues.apache.org/jira/browse/JCR-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521409
]
Julian Reschke commented on JCR-1070:
-
I'm in favor of this. If there's anything specific I can do to help, please
Christoph Kiehl wrote:
Marcel Reutegger wrote:
1) New QueryHandler class
2) Introduce parameter in configuration
3) Auto-detect in SearchIndex
I prefer 1) because it makes it explicit. I have reservations
regarding 3) because it introduces some magic. I don't like 2) because
we probably cann
Hi,
> a larger binary
> A simple insert of 10MB will look up JR for few seconds, this is quite a
> problem IMO.
Sounds like multiple connections would help here... I didn't really
think about large binaries so far, because I thought they are usually
processed by the blob store (or global data sto
Ard Schrijvers wrote:
Sorry for interfering with this performance thing, but it is very similar
problem to our lucene impl we build on top of slide some time ago (the index
was not ACL aware, so how to know the actual number of hits which are visible
for a user without having to test all nodes),
Thomas Mueller wrote:
>> avoid the synchronization on the PreparedStatements
>>
>
> I don't think that synchronization on prepared statements is a
> bottleneck. But you can prove that I am wrong. If writing the
> changelog is synchronized (not sure if it is), that would be a
> bottleneck.
>
>
Promotion of SPI from Contrib
-
Key: JCR-1070
URL: https://issues.apache.org/jira/browse/JCR-1070
Project: Jackrabbit
Issue Type: Task
Reporter: angela
Priority: Minor
This has been sugge
> avoid the synchronization on the PreparedStatements
I don't think that synchronization on prepared statements is a
bottleneck. But you can prove that I am wrong. If writing the
changelog is synchronized (not sure if it is), that would be a
bottleneck.
Thomas
Hi Michi,
> well, I want my local filesystem accessible via JCR and allowing me to
> change files still with "vi(m)" from time to time.
> Or do you consider that covered by A, B or C? But I guess my usecase is
> probably neglectable as a usecase ...
I usually use a webdav or an smb mount to be abl
On 8/21/07, Michael Wechner <[EMAIL PROTECTED]> wrote:
> well, I want my local filesystem accessible via JCR and allowing me to
> change files still with "vi(m)" from time to time
This works, whatever storage mechanism is used, but in the opposite
way: you can mount a Jackrabbit repositor
David Nuescheler wrote:
hi all,
i can appreciate both positions, looking at jackrabbit as the datastore
or looking at jackrabbit as running on top of a datastore (rdbms).
personally, i don't believe that the latter perception will go away for
quite a while, so i think jackrabbit should suppor
Hi,
[Branching the thread]
On 8/21/07, Thomas Mueller <[EMAIL PROTECTED]> wrote:
> My question is: should we support multiple connections in the
> persistence manager?
>
> If using multiple connections really does improve performance /
> scalability of Jackrabbit, I think we should think about it
Hi,
For me, the question is not really databases or not (databases need to
be supported, while native storage can be much faster).
My question is: should we support multiple connections in the
persistence manager?
If using multiple connections really does improve performance /
scalability of Jac
Hi,
On 8/20/07, Thomas Mueller <[EMAIL PROTECTED]> wrote:
> > management won't.
> > political reasons.
> > won't move to Jackrabbit *if* Jackrabbit cannot store it in oracle.
>
> I agree. My guess is about 50% of larger organizations want a
> databases as the backend, even if databases are slower.
[
https://issues.apache.org/jira/browse/JCR-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521347
]
angela commented on JCR-996:
Follow up discussion 'Distribution of commons classes':
http://www.mail-archive.com/dev@jackra
hi all,
i can appreciate both positions, looking at jackrabbit as the datastore
or looking at jackrabbit as running on top of a datastore (rdbms).
personally, i don't believe that the latter perception will go away for
quite a while, so i think jackrabbit should support both views.
in my experi
53 matches
Mail list logo
