Hello,
For some time I am battling with the queries in Jackrabbit v2.0.
For some reason all my query results (QueryResult .getNodes() ) are
resulting in a -1 size, I guess this indicates an error, otherwise it should
be 0.
Even the simple SELECT * from nt:base returns -1.
The same code works
Ac... now I see... I did rely on the getSize() method of the
NodeIterator.
Looking through the docs and the mailinglist I see that there is no real way
of retrieving the number of results?
gr,
Jacco
On Wed, Feb 17, 2010 at 10:44 AM, Jukka Zitting jukka.zitt...@gmail.comwrote:
Hi,
Hi! You can get size if you use 'order by' clause in your query.
Thanks!
On Feb 17, 2010, at 10:13 PM, Jacco van Weert softw...@gmail.com
wrote:
Ac... now I see... I did rely on the getSize() method of the
NodeIterator.
Looking through the docs and the mailinglist I see that
Hi everyone,
I've been thinking about starting a
clojure-contribhttp://github.com/richhickey/clojure-contrib-style
library for the JCR API. When I googled around for an existing project, I
found the cljcr project stub in Jukka's github:
http://github.com/jukka/cljcr
I'd just like to know if
Hello Marcus,
Yes that works, thanks... the only point is that probably this isn't
backupped by the docs.
So there might be a chance that in later revisions this also won't work.
In the end I think there should be a supported way to retrieve the number of
results.
gr,
Jacco
On Wed, Feb 17,
Hi,
On Wed, Feb 17, 2010 at 3:05 PM, Adam Foltzer acfolt...@gmail.com wrote:
I've been thinking about starting a clojure-contrib-style library for the
JCR API. When I googled around for an existing project, I found the cljcr
project stub in Jukka's github: http://github.com/jukka/cljcr
I'd
On Wed, Feb 17, 2010 at 2:14 PM, Jacco van Weert softw...@gmail.com wrote:
Hello Marcus,
Yes that works, thanks... the only point is that probably this isn't
backupped by the docs.
Not always working on 2.0-alpha12 (when has where condition) :(
WORKING: select * from [nt:base] order by
Hi,
Thanks for all the responses to the repository requirements thread
(keep 'em coming)! That's very valuable information when we start
looking deeper at the architectural changes and tradeoffs ahead of us.
The main concepts of the current Jackrabbit 1.x/2x. architecture date
back to almost a
Hi,
Having the search index stored on the normal file system gives us
great performance and avoids having to tweak Lucene too much to suit
our needs. However, the extra storage mechanism adds all sorts of
consistency, backup and transaction complexities.
Especially with things like the data
Hi,
In addition to the search index (that deserves it's own thread), we
have various different mechanisms for persisting repository
information:
persistence managers for node and property states
data store for binary properties
journal for cluster synchronization records
file
You can always iterate over the full result set and count yourself.
The -1 in recent jackrabbit versions comes from performance
improvements, that will make searches faster because the jr search
implementation does not have to load the full result set (from
lucene). The order by trick works
On Wed, Feb 17, 2010 at 16:22, Jukka Zitting jukka.zitt...@gmail.com wrote:
What would we need to do to achieve this, and would the result be
worth the effort?
Some ideas from the top of my head:
A basic problem is that the search index would include itself, so
maybe one has to have a separate
Currently, we index *all* properties into the same Lucene field. There
is an issue for this already [1]. I think we can gain a lot by having
each property indexed in its own Lucene field. This avoids that we
need to do so many custom queries and keep caches of terms ourselves,
which end up in
Hi,
Assuming we have a unified persistence layer (see the other thread),
it should be possible to implement a relatively simple repository
microkernel that implements just enough functionality for higher
level components like search, versioning, node types, observation,
etc. to be implemented on
On Wed, Feb 17, 2010 at 4:47 PM, Alexander Klimetschek aklim...@day.com wrote:
On Wed, Feb 17, 2010 at 16:22, Jukka Zitting jukka.zitt...@gmail.com wrote:
What would we need to do to achieve this, and would the result be
worth the effort?
From the top of my head we should also closely think
On Wed, Feb 17, 2010 at 16:33, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
In addition to the search index (that deserves it's own thread), we
have various different mechanisms for persisting repository
information:
persistence managers for node and property states
data store
+1
For simple search a built-in index would help a lot, for example node
names and (some) property values. Each property name could have its
own index. Advantages:
- transactional index updates
- reduced complexity
- reduced number of open files
- allows to implement Jackrabbit in C
I would not
Hi,
Regardless of whether we go with a microkernel approach as discussed
in the other thread, making Jackrabbit more modular and extensible
would be quite useful. Besides the design benefits, plugin
architectures typically also increase community participation as they
make it easier to customize
spi2davex NodeInfoImpl should use HashSet instead of ArrayList for childInfos
-
Key: JCR-2500
URL: https://issues.apache.org/jira/browse/JCR-2500
Project: Jackrabbit Content
Hi
each property indexed in its own Lucene field
Could you explain in more details? What is a 1:1 mapping? Do you mean
each property type should have it's own index, or each property name
should have its own index? Would this not increase the number of
Lucene index files a lot?
Regards,
Thomas
[
https://issues.apache.org/jira/browse/JCR-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved JCR-2500.
Resolution: Fixed
Fix Version/s: 2.1.0
Fixed at revision 911050
spi2davex NodeInfoImpl
Hi,
This one's a quite frequently asked feature. Currently we store the
full list of child nodes in the same bundle or node state record with
the parent node. This makes it expensive to support nodes with large
amounts (1k) of child nodes.
The obvious solution to this problem is to use a data
Hi,
On Wed, Feb 17, 2010 at 5:00 PM, Alexander Klimetschek aklim...@day.com wrote:
I think a good idea (and I guess this is what you have in mind) would
be to have a lower-level persistence API that is journal/cluster-aware
and allows for all the basic node and property storage.
Agreed. The
Hi,
On Wed, Feb 17, 2010 at 4:51 PM, Ard Schrijvers
a.schrijv...@onehippo.com wrote:
Also still, I really doubt about whether it is feasible to implement
in a performant way
The key performance problem we faced earlier with non-local search
indexes was the lack of efficient random access read
Hi,
I would implement the storage layer ourselves. It could look like:
- FileDataStore: keep as is (maybe reduce the directory level by one).
- Each node has a number (I would use a long). Used for indexing.
- MainStorage: the node data is kept in an append-only main
persistence storage. When
Hi,
On Wed, Feb 17, 2010 at 4:11 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
[...] Now that we're done implementing the new features and
changes for JCR 2.0, it's a good time to discuss what we can and
should make to modernize the Jackrabbit architecture.
BTW, this doesn't mean that
Jukka Zitting wrote:
Hi,
Regardless of whether we go with a microkernel approach as discussed
in the other thread, making Jackrabbit more modular and extensible
would be quite useful. Besides the design benefits, plugin
architectures typically also increase community participation as they
[
https://issues.apache.org/jira/browse/JCR-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834838#action_12834838
]
Daniel Hopper commented on JCR-2003:
What is the timeline for getting these various SPI
[
https://issues.apache.org/jira/browse/JCR-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834841#action_12834841
]
angela commented on JCR-2003:
-
we don't have any timeline for this.
we will work on this as time
Hi,
As discussed already before, switching from the current design where
all writes essentially block all concurrent repository access to a
MVCC design that decouples all read access from concurrent writes
would help us solve a number of performance bottlenecks. In addition
to the performance
[
https://issues.apache.org/jira/browse/JCR-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834843#action_12834843
]
Daniel Hopper commented on JCR-2003:
Thanks for the prompt response.
If that is the case
Hi,
This is somewhat related to the unified persistence and microkernel
ideas. Instead of keeping the different workspaces and the version
storage in separate storage locations it might be useful for a
repository to have just a single underlying content hierarchy whose
subtrees are seen as
[
https://issues.apache.org/jira/browse/JCR-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834852#action_12834852
]
angela commented on JCR-2003:
-
if you need the missing parts of JSR 283 in jcr2spi and the SPI
Hi,
We currently have two parallel implementations of the transient layer
in JCR, one in jackrabbit-core and one in jackrabbit-jcr2spi. Ideally
we'd only have a single implementation and have jackrabbit-core
implement the SPI instead of the JCR interfaces. That's probably not
doable any time soon
Hi,
The most obvious trouble with this approach is that the node UUIDs
would no longer be unique within such a super-workspace. I'm not sure
how to best solve that problem, apart from switching to some
alternative internal node identifiers. Any ideas?
Use a number (variable size when stored
On Wed, Feb 17, 2010 at 18:06, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
As discussed already before, switching from the current design where
all writes essentially block all concurrent repository access to a
MVCC design that decouples all read access from concurrent writes
would help
On Wed, Feb 17, 2010 at 18:16, Jukka Zitting jukka.zitt...@gmail.com wrote:
This is somewhat related to the unified persistence and microkernel
ideas. Instead of keeping the different workspaces and the version
storage in separate storage locations it might be useful for a
repository to have
Hi,
Sorry to kick in the discussion, I made an implementation of JCR last
septembre for our geographic information system.
While doing it I found one annoying point in the current specification.
If you can take a minute to read the following.
As you know all, jcr is designed to manage datas
On Wed, Feb 17, 2010 at 21:58, Johann Sorel johann.so...@geomatys.com wrote:
Sorry to kick in the discussion, I made an implementation of JCR last
septembre for our geographic information system.
While doing it I found one annoying point in the current specification.
If you can take a minute
On Wed, Feb 17, 2010 at 22:57, Alexander Klimetschek aklim...@day.com wrote:
...Real object databases would be close
to what you have in mind, but they always have the advantage ...
Disadvantage, of course.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
Repository descriptor returns null for QUERY_LANGUAGES
--
Key: JCR-2501
URL: https://issues.apache.org/jira/browse/JCR-2501
Project: Jackrabbit Content Repository
Issue Type: Bug
Hi Jukka,
Interesting to see how we can get Jackrabbit ready for the next decade ;-)
Here is my feedback for the survey.
Scalability:
* How much content (number of documents/nodes, raw amount data in
GB/TB/PB) do you have in the repository?
In the order of tens of millions of nodes and tens
Hi,
Right now there are several homegrown caches in Jackrabbit. Some
configurable, some based on soft/weak references. Using JCache it
would make it possible to leverage existing caching implementations.
This could help in making the caches better configurable and tunable
and have features like
Alexander Klimetschek wrote:
On Wed, Feb 17, 2010 at 21:58, Johann Sorel johann.so...@geomatys.com wrote:
Sorry to kick in the discussion, I made an implementation of JCR last
septembre for our geographic information system.
While doing it I found one annoying point in the current
Since I've only ever submitted one patch to an ASF project, I'll go ahead
and use GitHub for now. I've been meaning to properly learn Git anyway, so
that'll be good motivation. Once the shape comes together, it could always
be moved.
As for the actual artifact, the clojure-contrib-sql API seems
My project has run into problems along these lines as a result of
clustering. Since our application servers are managed very strictly by a
centralized infrastructure group, we have no guarantees of having the same
filesystem available if we have to bring up another server to meet load or
balance a
On 2/17/10 5:29 PM, Bart van der Schans wrote:
Hi,
Right now there are several homegrown caches in Jackrabbit. Some
configurable, some based on soft/weak references. Using JCache it
would make it possible to leverage existing caching implementations.
This could help in making the caches
On 2/17/10 5:51 PM, Johann Sorel wrote:
Alexander Klimetschek wrote:
On Wed, Feb 17, 2010 at 21:58, Johann Sorel
johann.so...@geomatys.com wrote:
Sorry to kick in the discussion, I made an implementation of JCR last
septembre for our geographic information system.
While doing it I found
Jukka-
(Thanks for starting all these discussions...)
On 2/17/10 11:06 AM, Jukka Zitting wrote:
Hi,
Regardless of whether we go with a microkernel approach as discussed
in the other thread, making Jackrabbit more modular and extensible
would be quite useful. Besides the design benefits,
Jukka-
Just to clarify, you're talking about Jackrabbit 3, not JCR 3, right?
Thanks,
Justin
On 2/17/10 10:11 AM, Jukka Zitting wrote:
Hi,
Thanks for all the responses to the repository requirements thread
(keep 'em coming)! That's very valuable information when we start
looking deeper at
Hello.
I have recently started to use Jackrabbit for the new project. I have not
enough experience, but already there are some things which I wish see in
following versions.
* Remote access, i.e. standalone version of a server, completely compatible
with JCR2. For example, now neither webdav
Another example: importing large repository file (1GB)
Andrey
From: Thomas Müller thomas.muel...@day.com
To: dev dev@jackrabbit.apache.org
Sent: Wed, 17 February, 2010 20:05:18
Subject: [jr3] Support large transactions
Jackrabbit should support transactions
Hi,
For me, there are two kinds of indexes: the property/value indexes,
and the fulltext index.
The property/value indexes are for property values, node names, paths,
node references, and so on. Such indexes (or indices) are relatively
small and fast. In relational databases, those are the
Hi,
I would do MVCC in a similar way it is done in relational databases
such as PostgreSQL. See also
www.postgresql.org/files/developer/transactions.pdf
Concurrent writes and MVCC: usually MVCC means readers are never
blocked by other readers or writers, and writers are not blocked by
readers.
Hi,
About 'append only' and 'immutable' storage. Here is an interesting link:
http://eclipsesource.com/blogs/2009/12/13/persistent-trees-in-git-clojure-and-couchdb-data-structure-convergence/
Regards,
Thomas
55 matches
Mail list logo
