I'm wondering if anyone has a good idea how to model a queue with efficient
operations in JCR - or is JCR not suited for this use case?
Regards
Carsten
2014-07-30 15:57 GMT+02:00 Carsten Ziegeler :
> Using a different storage than JCR would be easy in my case, however I
> *want* to use JCR
>
>
Suppose we have a query like
select [jcr:path]
from [nt:base]
where id = '1' and x = '2'
Currently the property restrictions are maintained as a HashMap in
FilterImpl so above ordering information would be lost.
Such ordering information might be useful when querying against Lucene
index. Th
Would it be appropriate in this situation to adopt Oak indices and use
queries instead of "listChildren"?
On 7/31/14 4:56 AM, "Thomas Mueller" wrote:
>Hi,
>
>This might be a XY problem:
>http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem
>
>What problem do you want to solve?
On Thu, Jul 31, 2014 at 7:01 PM, Tommaso Teofili
wrote:
> as far as I know one workaround to trigger usage of a specific index is to
> use the native language supported by that specific index, but then that, of
> course, would require writing the query in a implementation specific way
> (e.g. sele
2014-07-31 15:20 GMT+02:00 Chetan Mehrotra :
> On Thu, Jul 31, 2014 at 5:23 PM, Thomas Mueller wrote:
> > You could simply have *multiple* index instances, and each index returns
> > its own cost or plan(s). The query engine will figure out which index to
> > use.
>
> Aah missed the fact that Que
Hello team,
as it's a crucial part of our development I'd like to ask you a review of
https://issues.apache.org/jira/browse/OAK-1855
so that we don't risk of loosing pieces here and there.
The commit linked in the ticket is a squash of several. If you want the
full list you can consult the long
On Thu, Jul 31, 2014 at 5:23 PM, Thomas Mueller wrote:
> You could simply have *multiple* index instances, and each index returns
> its own cost or plan(s). The query engine will figure out which index to
> use.
Aah missed the fact that QueryProvider can return multiple indexes.
That would simpli
Hi,
I'm not quite sure what you are trying to do. You don't need to do the
multiplexing *within* your index. Let the query engine do the multiplexing.
> Would it be safe to assume that IndexPlan instance returned from the
>getPlans call would be passed back in the {{query}} call?
Yes, the index
Hi,
This might be a XY problem:
http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem
What problem do you want to solve?
I don't think it's a good idea to have a list of 2 orderable children,
also because neither Jackrabbit 2.x nor Jackrabbit Oak can deal with this
efficiently
Hi,
While working on multiple Lucene index support (OAK-2005) I need to
make LuceneIndex implement the AdvanceQueryIndex. As part of OAK-2005
we would be having multiple Lucene indexes where each index would be
configured to store different types of data.
As part of getPlans call LuceneIndex woul
Hi,
Now that 1.0.3 is out, it's time to plan the next minor release.
Please tag issues with the 1.0.4 version for fixes you'd like to include.
I'm planning to cut the release today after lunch (in about 3 hours).
Regards
Thomas
Hi
Am 31.07.2014 um 09:12 schrieb Bertrand De Coatpont :
> Hello,
>
> In the JCR world, is there a specific API to obtain (for reading) a
> specific range of child nodes within a large list of orderable child nodes
> (e.g. Nodes 490-500 out of 2), and is OAK helping/changing anything in
> th
On 31 Jul 2014, at 09:12, Bertrand De Coatpont wrote:
> Hello,
>
> In the JCR world, is there a specific API to obtain (for reading) a
> specific range of child nodes within a large list of orderable child nodes
> (e.g. Nodes 490-500 out of 2), and is OAK helping/changing anything in
> this
Hello,
In the JCR world, is there a specific API to obtain (for reading) a
specific range of child nodes within a large list of orderable child nodes
(e.g. Nodes 490-500 out of 2), and is OAK helping/changing anything in
this area compared to previous versions?
Thanks!
Bertrand
Bertrand de
14 matches
Mail list logo