On 12.9.12 19:06, Michael Marth wrote:
As an alternative: we could use a separate method getSize(int max) which
* if called with max == -1 returns the exact size if quickly available,
* returns -1 otherwise, and
* returns the exact size but not more then max when called with max = 0.
This
Hi,
There's no need for the Oak API to reflect JCR in all its details.
Sure. First we need to define how the JCR API implementation is supposed
to behave. Based on that we can then still decide what the Oak API should
look like. The Oak API is (more or less) an implementation detail. Of
course
Hi,
The main question is still what the JCR API method getSize() should return.
A new method getSize(int max) is nice, and of course we can do that. But I
guess people will not use it in the near future because it's not part of
the JCR API.
Regards,
Thomas
On 9/12/12 8:06 PM, Michael Marth
Hi,
On Thu, Sep 13, 2012 at 9:56 AM, Thomas Mueller muel...@adobe.com wrote:
[...] When I opened OAK-300, it was for the JCR API implementation. [...]
Ah, I see, sorry for confusing the matter.
For the JCR API I'd simply start by ensuring that getSize() will
always return the correct size if
Hi,
return the correct size if the result set has fewer than
something like 1000 entries. That should cover most practical cases
Yes. Let's discuss the value now! 1000 sounds OK in general, however there
is a potential performance problem. For Jackrabbit 2.x, if there are more
than a few million
hi,
remapping an existing namespace prefix in the namespace registry
somewhat breaks existing content. say we create a node foo:test,
save it and then remap prefix 'foo' to 'bar' in the namespace registry.
reading the same node again will still return foo:bar, however 'foo'
is not valid namespace
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/529
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
This seems to be related to to my work on node type validation. I'll
have a look.
Michael
On 13.9.12 10:02, build...@apache.org wrote:
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
Hi,
On Thu, Sep 13, 2012 at 10:40 AM, Thomas Mueller muel...@adobe.com wrote:
Sounds good. I guess we could do both: always prefetch 20 nodes, and if
there is still time, fetch more up to 0.1 seconds or so, or at most 200
nodes. I guess 200 should be enough to for a GUI to decide what to
On 2012-09-13 10:47, Marcel Reutegger wrote:
hi,
remapping an existing namespace prefix in the namespace registry
somewhat breaks existing content. say we create a node foo:test,
save it and then remap prefix 'foo' to 'bar' in the namespace registry.
reading the same node again will still
How is Jackrabbit handling this?
Jackrabbit always stores names and path values with the namespace uri.
regards
marcel
On 2012-09-13 11:48, Marcel Reutegger wrote:
How is Jackrabbit handling this?
Jackrabbit always stores names and path values with the namespace uri.
Oh, indeed. For some reason, I thought we're doing that only in JCR2SPI
friends.
(and yes, I still think we should have done exactly that
On 2012-09-13 11:10, Jukka Zitting wrote:
Hi,
On Thu, Sep 13, 2012 at 10:47 AM, Marcel Reutegger mreut...@adobe.com wrote:
remapping an existing namespace prefix in the namespace registry
somewhat breaks existing content. say we create a node foo:test,
save it and then remap prefix 'foo' to
The Buildbot has detected a restored build on builder oak-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/530
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source
Hi,
On Thu, Sep 13, 2012 at 12:21 PM, Julian Reschke julian.resc...@gmx.de wrote:
On 2012-09-13 11:10, Jukka Zitting wrote:
The idea, not implemented yet, of how such things should be handled is
to have a commit hook that looks out for changes in registered
namespace prefixes and either a)
The Buildbot has detected a restored build on builder oak-trunk while building
ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/539
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source
This is expected. See
https://issues.apache.org/jira/browse/OAK-6?focusedCommentId=13454930page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13454930
Should be fixed in revision 1384355
Michael
On 13.9.12 16:02, build...@apache.org wrote:
The Buildbot has
Hi,
On Thu, Sep 6, 2012 at 9:37 PM, Philipp Marx (JIRA) j...@apache.org wrote:
Summary: MongoDB-based MicroKernel
This is a pretty major new feature so I'd like us to vote on whether
we want to take over the maintenance and further development of this
code. If we agree, I'd also suggest that we
And here's my:
+1
Kind regards
Dominique
On Sep 13, 2012, at 5:09 PM, Jukka Zitting wrote:
Hi,
On Thu, Sep 6, 2012 at 9:37 PM, Philipp Marx (JIRA) j...@apache.org wrote:
Summary: MongoDB-based MicroKernel
This is a pretty major new feature so I'd like us to vote on whether
we want to
Hi,
To read a node, the query engine currently uses:
session.getCurrentRoot().getTree(path);
The query engine calls this whenever it has to evaluate a property. It
turns out internally the getCurrentRoot() method always calls
MicroKernel.getHeadRevision(). I wonder if this is required, and
On 13.9.12 16:42, Thomas Mueller wrote:
Hi,
To read a node, the query engine currently uses:
session.getCurrentRoot().getTree(path);
The query engine calls this whenever it has to evaluate a property. It
turns out internally the getCurrentRoot() method always calls
On 2012-09-13 17:09, Jukka Zitting wrote:
Hi,
On Thu, Sep 6, 2012 at 9:37 PM, Philipp Marx (JIRA) j...@apache.org wrote:
Summary: MongoDB-based MicroKernel
This is a pretty major new feature so I'd like us to vote on whether
we want to take over the maintenance and further development of
Hi,
On Thu, Sep 13, 2012 at 5:42 PM, Thomas Mueller muel...@adobe.com wrote:
Should I cache the Root instance in the query engine for the duration of a
query? Or would it be possible to change the Root implementation so this
is not needed?
It would be better if the query engine used the same
On 13.09.2012, at 01:40, Thomas Mueller muel...@adobe.com wrote:
Sounds good. I guess we could do both: always prefetch 20 nodes, and if
there is still time, fetch more up to 0.1 seconds or so, or at most 200
nodes. I guess 200 should be enough to for a GUI to decide what to display
(10 pages
+1
greets
claus
Hi,
It would be better if the query engine used the same tree snapshot as
the rest of the session. There shouldn't be any need to call
getCurrentRoot().
This is actually what I expected that ContentSession.getCurrentRoot()
would provide me: I expected getCurrentRoot() would always return the
Hi,
The idea with the timeout sounds good, but what should we recommend an
application to do if getSize() takes too long and returns -1?
Imagine while paging search results, the first page query is fast enough
(getSize() returns something), but the second is too long and now returns
-1: should
27 matches
Mail list logo
