On 09.06.2015, at 22:24, Carsten Ziegeler cziege...@apache.org wrote:
If you mean whatever query language is supported by mongo or other nosql
providers (and fits into a string), then that's the best you can do on the
Sling layer.
Thanks for confirming my point why an abstraction is
On 04.06.2015, at 21:56, Carsten Ziegeler cziege...@apache.org wrote:
Ok, could you then please provide an implementation for the mongo
resource provider or one of the other nosql providers?
If you mean jcr xpath (or any other jcr/oak supported query language), no.
If you mean whatever query
Am 09.06.15 um 21:01 schrieb Alexander Klimetschek:
On 04.06.2015, at 21:56, Carsten Ziegeler cziege...@apache.org wrote:
Ok, could you then please provide an implementation for the mongo
resource provider or one of the other nosql providers?
If you mean jcr xpath (or any other jcr/oak
Am 04.06.15 um 15:52 schrieb Alexander Klimetschek:
On 03.06.2015, at 14:52, Carsten Ziegeler cziege...@apache.org wrote:
Well, let's agree that we disagree here. For the majority of users,
there is only JCR anyway, which means there is no difference between
using a nice api and fiddling with
On 03.06.2015, at 14:52, Carsten Ziegeler cziege...@apache.org wrote:
Well, let's agree that we disagree here. For the majority of users,
there is only JCR anyway, which means there is no difference between
using a nice api and fiddling with strings by hand when it comes to
performance.
And
Am 03.06.15 um 11:40 schrieb Alexander Klimetschek:
On 02.06.2015, at 16:39, Carsten Ziegeler cziege...@apache.org wrote:
The query contains the sort information (which properties and whether
ascending or descending), so you can get the values of the props and
compare them.
But then you
On 02.06.2015, at 16:39, Carsten Ziegeler cziege...@apache.org wrote:
The query contains the sort information (which properties and whether
ascending or descending), so you can get the values of the props and
compare them.
But then you need to
a) be able to understand and fully evaluate the
On Wed, May 27, 2015 at 10:35 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
...I'd
like to discuss what the alternatives are, before we invent YAQA (*)...
FWIW I've played a bit with the Oak query code to see if its parsers
are reusable.
That's not the case out of the box but it looks
On 02.06.2015, at 05:17, Daniel Klco daniel.k...@gmail.com wrote:
@Alex,
Sorting wouldn't necessarily be slow. What you could do is have the API
return an iterator which wraps the sorted result iterator from the various
resource providers.
And how do you know that result X from provider A
Am 02.06.15 um 12:32 schrieb Alexander Klimetschek:
On 02.06.2015, at 05:17, Daniel Klco daniel.k...@gmail.com wrote:
@Alex,
Sorting wouldn't necessarily be slow. What you could do is have the API
return an iterator which wraps the sorted result iterator from the various
resource providers.
@Alex,
Sorting wouldn't necessarily be slow. What you could do is have the API
return an iterator which wraps the sorted result iterator from the various
resource providers. This iterator would keep track of the next value of
the iterator from every resource provider result and return the
Am 02.06.15 um 01:39 schrieb Bertrand Delacretaz:
On Wed, May 27, 2015 at 10:35 AM, Bertrand Delacretaz
FWIW I've played a bit with the Oak query code to see if its parsers
are reusable.
That's not the case out of the box but it looks like refactoring Oak's
SQL2Parser and
One thing we have to think of is how to use pagination and sorting.
A search could go across the whole resource tree hitting different
resource providers. For example one use case is getting all vanity paths.
Sorting such a search is possible, the resource resolver implementation
always picks one
On 30.05.2015, at 01:31, Stefan Seifert sseif...@pro-vision.de wrote:
And this is a typical case where abstraction fails: performance. Which is
extremely important for queries.
Well, this is a broad statement and neither true nor wrong.
i'm the same opinion as carsten. i did a quick
But do you have queries across resource providers? Do you know the
implementation complexity and performance limitations you are asking for?
no, i never required searching across different providers in the past, it would
even be ok for me to not support cross-provider searching in the beginning
On 01.06.2015, at 08:50, Carsten Ziegeler cziege...@apache.org wrote:
So I think, we should support sorting across providers
This means sorting will be very slow. Since you have to re-sort the partial
results on the sling level without usage of an index.
Cheers,
Alex
Am 01.06.15 um 13:58 schrieb Alexander Klimetschek:
But do you have queries across resource providers? Do you know the
implementation complexity and performance limitations you are asking for?
If you have different resource providers with their own search index, and you
have to aggregate
Am 01.06.15 um 14:00 schrieb Alexander Klimetschek:
On 01.06.2015, at 08:50, Carsten Ziegeler cziege...@apache.org wrote:
So I think, we should support sorting across providers
This means sorting will be very slow. Since you have to re-sort the partial
results on the sling level without
Am 30.05.15 um 10:31 schrieb Stefan Seifert:
btw. i assume we do not remove the old support for directly passing a query
string to the resource resolver, but add the additional support for the
abstraction? this would allow experienced developers who now they are only
using JCR still use
Am 30.05.15 um 03:17 schrieb Alexander Klimetschek:
On 28.05.2015, at 23:08, Carsten Ziegeler cziege...@apache.org wrote:
I agree with this, however users of the resource api do not know which
provider is serving the resources. That's the hole point of an abstraction.
And this is a typical
And this is a typical case where abstraction fails: performance. Which is
extremely important for queries.
Well, this is a broad statement and neither true nor wrong.
i'm the same opinion as carsten. i did a quick check for the most queries in
our projects from the last years and most of them
Am 29.05.15 um 01:13 schrieb Alexander Klimetschek:
On 28.05.2015, at 09:32, Carsten Ziegeler cziege...@apache.org wrote:
Am 28.05.15 um 18:25 schrieb Alexander Klimetschek:
On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote:
I'm happy to collaborate on creating these
Am 29.05.15 um 01:16 schrieb Alexander Klimetschek:
When you run a query across multiple backends, you have to aggregate the
results. This is non-trivial an in most cases you are better off using an
external search index that covers everything. And from my experience, you
usually you don't
On 28.05.2015, at 23:08, Carsten Ziegeler cziege...@apache.org wrote:
I agree with this, however users of the resource api do not know which
provider is serving the resources. That's the hole point of an abstraction.
And this is a typical case where abstraction fails: performance. Which is
On 28.05.2015, at 23:07, Carsten Ziegeler cziege...@apache.org wrote:
No, it's both. It is a normal API [1], usage example at [2], but it also has
a form that is easy to transport over http using GET/POST parameters and
comes with a (popular) servlet that provides the result as json. The
On 28.05.2015, at 09:32, Carsten Ziegeler cziege...@apache.org wrote:
Am 28.05.15 um 18:25 schrieb Alexander Klimetschek:
On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote:
I'm happy to collaborate on creating these examples (which can simply
be unit tests for a
When you run a query across multiple backends, you have to aggregate the
results. This is non-trivial an in most cases you are better off using an
external search index that covers everything. And from my experience, you
usually you don't have the use case to search across different providers,
Just to clarify as it seems people got the proposal wrong: this is about
a new API, not an implementation. It's an abstraction on the resource
level. Of course with a JCR provider underneath, the search is delegated
to that provider. Same with other providers.
It should be easy for every provider
On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote:
I'm happy to collaborate on creating these examples (which can simply
be unit tests for a relevant ResourceProvider) but before that I'd
like to discuss what the alternatives are, before we invent YAQA (*).
We have the
Am 28.05.15 um 18:25 schrieb Alexander Klimetschek:
On 27.05.2015, at 01:35, Bertrand Delacretaz bdelacre...@apache.org wrote:
I'm happy to collaborate on creating these examples (which can simply
be unit tests for a relevant ResourceProvider) but before that I'd
like to discuss what the
Hi,
On Mon, May 18, 2015 at 8:17 AM, Carsten Ziegeler cziege...@apache.org wrote:
The current resource query api has several problems:
- it's using the JCR spec to define a query..
Why is that a problem?
Creating a good query API is hard work, so I'd be much more in favor
of reusing an
Am 27.05.15 um 10:35 schrieb Bertrand Delacretaz:
Hi,
On Mon, May 18, 2015 at 8:17 AM, Carsten Ziegeler cziege...@apache.org
wrote:
The current resource query api has several problems:
- it's using the JCR spec to define a query..
Why is that a problem?
Creating a good query API is
5. full text search on any property (jcr:contains) - is this possible with
.property(*).approx(searchterm)? or perhaps something
like .anyProperty().approx(searchtearm) - or a special signature
like .anyPropertyApprox(searchtearm)?
Haven't thought about this one yet, but I guess a special
Am 26.05.15 um 22:10 schrieb Stefan Seifert:
5. full text search on any property (jcr:contains) - is this possible with
.property(*).approx(searchterm)? or perhaps something
like .anyProperty().approx(searchtearm) - or a special signature
like .anyPropertyApprox(searchtearm)?
Haven't
I changed my mind and went with property(*) - the main reason is to
keep the query interface smaller as that needs to be interpreted by the
providers.
ok
stefan
I've updated the API with the feedback I received so far. In addition I
changed the paging from a skip number to key based paging. I guess these
interfaces are not perfect yet, but show the direction.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
6. property conditions with deep property paths should be supported as well
- if the underlying provider supports it. so .property() could optionally
accept a path to a deeper property. to clarify in javadocs.
I'm not sure if we should go there, so your use case is searching for a
resource
Thanks for your feedback Stefan, more inline...
Am 21.05.15 um 13:00 schrieb Stefan Seifert:
1. Query can reference further Queryies for nesting with and/or expressions.
in this case the sort* methods do not make sense. perhaps the two sort
methods should be moved to QueryInstructions?
hello carsten.
some feedback:
1. Query can reference further Queryies for nesting with and/or expressions. in
this case the sort* methods do not make sense. perhaps the two sort methods
should be moved to QueryInstructions?
2. it would be useful not only to filter by property values, but by
39 matches
Mail list logo
