On Mon, Apr 16, 2012 at 9:59 PM, Vincent Massol <[email protected]> wrote:

Hi,

On Apr 16, 2012, at 8:10 PM, Jean-Vincent Drean wrote:

...

Hi devs,

while replacing calls to xwiki#searchDocuments by calls to the query manager script service I ran into the following query manager issue: http://jira.xwiki.org/browse/XWIKI-7273 (XWQL short form queries should distinct on document fullname.)

I think we could use the recent QueryFilter mechanism to handle the addition of the "distinct" in the select statement. https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...

QueryFilters allow to: - transform queries depending on a dynamic parameter (for example the user preferences in HiddenDocumentFilter) - transform the select part of a short query, without requiring programming rights

Here's an example of what it could look like from a velocity script: ----------------------------------------------------8<---------------------------------------------------- #set($query = $services.query.xwql("").addFilter("unique").addFilter("hidden")) ----------------------------------------------------8<---------------------------------------------------- Note that in the future we could decide that the Query wrapper we use in the QueryManagerScriptService (ScriptQuery) have the "unique" filter by default + a way to remove it from the script.

I wasn't expecting us to consider using multiple filters when I added the new APIs in Query (4.0RC1). If we agree that a QueryFilter would be a nice way to handle this, I'd like to break those API before we release 4.0: ----------------------------------------------------8<---------------------------------------------------- -    Query setFilter(QueryFilter filter); +    Query addFilter(QueryFilter filter); -    QueryFilter getFilter(); +    List<QueryFilter> getFilters(); ----------------------------------------------------8<----------------------------------------------------

It's a little bit more complex. We did consider several filters when we added setFilter()!! :)

We said that if we need more than one filter we could have an AndFilter() that takes a list of Filters. And allow more complex filters should we need them, like OrFilter, etc.

#set($query = $services.query.xwql("").setFilter(new AndFilter("unique", "hidden"))

Written with a fluent API that would give:

#set($query = $services.query.xwql("").setFilter(and("unique", "hidden"))

Or even:

#set($query = $services.query.xwql("").setFilter("unique").and("hidden")

Anyway I'm just mentioning this to explain what we thought about and an alternative to addFilter(). The only problem with addFilter() is if you need more complex Filters later on. It's not extensible whereas using AndFilter() and OrFilter() is more extensible at the expense of a little bit more text if not using a fluent api.

Also you can't expose it that easily in velocity. For example your fluent APIs examples above won't work in velocity ; you would need a layer in between to adapt from script service APIs to the Java APIs. Jerome.

Anyway I'm fine with either addFilter or setFilter.

Also +1 to use a QueryFilter for adding a "distinct" in the query.

Thanks -Vincent

...

WDYT ? JV.

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jérôme Velociter Winesquare http://www.winesquare.net/

On Apr 16, 2012, at 11:11 PM, Vincent Massol wrote:

On Apr 16, 2012, at 10:23 PM, Jerome Velociter wrote:

...

On Mon, Apr 16, 2012 at 9:59 PM, Vincent Massol <[email protected]> wrote:

...

Hi,

On Apr 16, 2012, at 8:10 PM, Jean-Vincent Drean wrote:

...

Hi devs,

while replacing calls to xwiki#searchDocuments by calls to the query manager script service I ran into the following query manager issue: http://jira.xwiki.org/browse/XWIKI-7273 (XWQL short form queries should distinct on document fullname.)

I think we could use the recent QueryFilter mechanism to handle the addition of the "distinct" in the select statement. https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...

QueryFilters allow to: - transform queries depending on a dynamic parameter (for example the user preferences in HiddenDocumentFilter) - transform the select part of a short query, without requiring programming rights

Here's an example of what it could look like from a velocity script: ----------------------------------------------------8<---------------------------------------------------- #set($query = $services.query.xwql("").addFilter("unique").addFilter("hidden")) ----------------------------------------------------8<---------------------------------------------------- Note that in the future we could decide that the Query wrapper we use in the QueryManagerScriptService (ScriptQuery) have the "unique" filter by default + a way to remove it from the script.

I wasn't expecting us to consider using multiple filters when I added the new APIs in Query (4.0RC1). If we agree that a QueryFilter would be a nice way to handle this, I'd like to break those API before we release 4.0: ----------------------------------------------------8<---------------------------------------------------- - Query setFilter(QueryFilter filter); + Query addFilter(QueryFilter filter); - QueryFilter getFilter(); + List<QueryFilter> getFilters(); ----------------------------------------------------8<----------------------------------------------------

It's a little bit more complex. We did consider several filters when we added setFilter()!! :)

We said that if we need more than one filter we could have an AndFilter() that takes a list of Filters. And allow more complex filters should we need them, like OrFilter, etc.

#set($query = $services.query.xwql("").setFilter(new AndFilter("unique", "hidden"))

Written with a fluent API that would give:

#set($query = $services.query.xwql("").setFilter(and("unique", "hidden"))

Or even:

#set($query = $services.query.xwql("").setFilter("unique").and("hidden")

Anyway I'm just mentioning this to explain what we thought about and an alternative to addFilter(). The only problem with addFilter() is if you need more complex Filters later on. It's not extensible whereas using AndFilter() and OrFilter() is more extensible at the expense of a little bit more text if not using a fluent api.

Also you can't expose it that easily in velocity. For example your fluent APIs examples above won't work in velocity ; you would need a layer in between to adapt from script service APIs to the Java APIs.

You can't do a "new" but the point of the fluent API is to not have to write any "new" (to make it fluent) and thus it's well adapted to Velocity actually :)

BTW on http://en.wikipedia.org/wiki/Fluent_interface#Java their examples shows a usage where they call setParameter several times.

This is also a possibility. We can call setFilter() several times.

BTW another possibility is: ...setFilter("unique").and().setFilter("hidden") I had found a nice blog post on how to implement chaining like this with an order but I cannot find it again. Thanks -Vincent

Thanks -Vincent

...

Jerome.

...

Anyway I'm fine with either addFilter or setFilter.

Also +1 to use a QueryFilter for adding a "distinct" in the query.

Thanks -Vincent

...

WDYT ? JV.

On 04/16/2012 08:16 PM, Jerome Velociter wrote:

On Mon, Apr 16, 2012 at 11:26 PM, Vincent Massol<[email protected]> wrote:

...

On Apr 16, 2012, at 11:11 PM, Vincent Massol wrote:

...

On Apr 16, 2012, at 10:23 PM, Jerome Velociter wrote:

...

On Mon, Apr 16, 2012 at 9:59 PM, Vincent Massol<[email protected]> wrote:

...

Hi,

On Apr 16, 2012, at 8:10 PM, Jean-Vincent Drean wrote:

...

Hi devs,

while replacing calls to xwiki#searchDocuments by calls to the query manager script service I ran into the following query manager issue: http://jira.xwiki.org/browse/XWIKI-7273 (XWQL short form queries should distinct on document fullname.)

I think we could use the recent QueryFilter mechanism to handle the addition of the "distinct" in the select statement. https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...

QueryFilters allow to: - transform queries depending on a dynamic parameter (for example the user preferences in HiddenDocumentFilter) - transform the select part of a short query, without requiring programming rights

Here's an example of what it could look like from a velocity script: ----------------------------------------------------8<---------------------------------------------------- #set($query = $services.query.xwql("").addFilter("unique").addFilter("hidden")) ----------------------------------------------------8<---------------------------------------------------- Note that in the future we could decide that the Query wrapper we use in the QueryManagerScriptService (ScriptQuery) have the "unique" filter by default + a way to remove it from the script.

I wasn't expecting us to consider using multiple filters when I added the new APIs in Query (4.0RC1). If we agree that a QueryFilter would be a nice way to handle this, I'd like to break those API before we release 4.0: ----------------------------------------------------8<---------------------------------------------------- - Query setFilter(QueryFilter filter); + Query addFilter(QueryFilter filter); - QueryFilter getFilter(); + List<QueryFilter> getFilters(); ----------------------------------------------------8<----------------------------------------------------

It's a little bit more complex. We did consider several filters when we added setFilter()!! :)

We said that if we need more than one filter we could have an AndFilter() that takes a list of Filters. And allow more complex filters should we need them, like OrFilter, etc.

#set($query = $services.query.xwql("").setFilter(new AndFilter("unique", "hidden"))

Written with a fluent API that would give:

#set($query = $services.query.xwql("").setFilter(and("unique", "hidden"))

Or even:

#set($query = $services.query.xwql("").setFilter("unique").and("hidden")

Anyway I'm just mentioning this to explain what we thought about and an alternative to addFilter(). The only problem with addFilter() is if you need more complex Filters later on. It's not extensible whereas using AndFilter() and OrFilter() is more extensible at the expense of a little bit more text if not using a fluent api.

Also you can't expose it that easily in velocity. For example your fluent APIs examples above won't work in velocity ; you would need a layer in between to adapt from script service APIs to the Java APIs.

You can't do a "new" but the point of the fluent API is to not have to write any "new" (to make it fluent) and thus it's well adapted to Velocity actually :)

BTW on http://en.wikipedia.org/wiki/Fluent_interface#Java their examples shows a usage where they call setParameter several times.

This is also a possibility. We can call setFilter() several times.

BTW another possibility is:

...setFilter("unique").and().setFilter("hidden")

To me the "or" filter combination does not make sense in this context - filters aren't booleans AFAIK ; so I don't think this type of chaining brings anything compared to addFilter("unique").addFilter("hidden")

I tried to find some use cases for different combinators, and I did. For example, in the blog application, we have some queries that say "give me the blog posts that are published and not hidden, or created by the current user". Sure, this query could be written directly as a query, but the idea remains: we could write filters like "hasCurrentUserAsAuthor" and "isPublished" (as a custom filter provided by the Blog module), and combine them using OR. Now, the question is: do we want to provide such filtering as query filters, or should we only allow that explicitly in the XWQL? Personally I'd go for the simpler solution, and only have an addFilter method, and leave everything else for the actual query.

Jerome

...

I had found a nice blog post on how to implement chaining like this with an order but I cannot find it again.

Thanks -Vincent

...

Thanks -Vincent

...

Jerome.

...

Anyway I'm fine with either addFilter or setFilter.

Also +1 to use a QueryFilter for adding a "distinct" in the query.

Thanks -Vincent

...

WDYT ? JV.

-- Sergiu Dumitriu http://purl.org/net/sergiu/

On Mon, Apr 16, 2012 at 11:11 PM, Vincent Massol <[email protected]> wrote:

On Apr 16, 2012, at 10:23 PM, Jerome Velociter wrote:

...

On Mon, Apr 16, 2012 at 9:59 PM, Vincent Massol <[email protected]> wrote:

...

Hi,

On Apr 16, 2012, at 8:10 PM, Jean-Vincent Drean wrote:

...

Hi devs,

while replacing calls to xwiki#searchDocuments by calls to the query manager script service I ran into the following query manager issue: http://jira.xwiki.org/browse/XWIKI-7273 (XWQL short form queries should distinct on document fullname.)

I think we could use the recent QueryFilter mechanism to handle the addition of the "distinct" in the select statement. https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...

QueryFilters allow to: - transform queries depending on a dynamic parameter (for example the user preferences in HiddenDocumentFilter) - transform the select part of a short query, without requiring programming rights

Here's an example of what it could look like from a velocity script: ----------------------------------------------------8<---------------------------------------------------- #set($query = $services.query.xwql("").addFilter("unique").addFilter("hidden")) ----------------------------------------------------8<---------------------------------------------------- Note that in the future we could decide that the Query wrapper we use in the QueryManagerScriptService (ScriptQuery) have the "unique" filter by default + a way to remove it from the script.

I wasn't expecting us to consider using multiple filters when I added the new APIs in Query (4.0RC1). If we agree that a QueryFilter would be a nice way to handle this, I'd like to break those API before we release 4.0: ----------------------------------------------------8<---------------------------------------------------- -    Query setFilter(QueryFilter filter); +    Query addFilter(QueryFilter filter); -    QueryFilter getFilter(); +    List<QueryFilter> getFilters(); ----------------------------------------------------8<----------------------------------------------------

It's a little bit more complex. We did consider several filters when we added setFilter()!! :)

We said that if we need more than one filter we could have an AndFilter() that takes a list of Filters. And allow more complex filters should we need them, like OrFilter, etc.

#set($query = $services.query.xwql("").setFilter(new AndFilter("unique", "hidden"))

Written with a fluent API that would give:

#set($query = $services.query.xwql("").setFilter(and("unique", "hidden"))

Or even:

#set($query = $services.query.xwql("").setFilter("unique").and("hidden")

Anyway I'm just mentioning this to explain what we thought about and an alternative to addFilter(). The only problem with addFilter() is if you need more complex Filters later on. It's not extensible whereas using AndFilter() and OrFilter() is more extensible at the expense of a little bit more text if not using a fluent api.

Also you can't expose it that easily in velocity. For example your fluent APIs examples above won't work in velocity ; you would need a layer in between to adapt from script service APIs to the Java APIs.

You can't do a "new" but the point of the fluent API is to not have to write any "new" (to make it fluent) and thus it's well adapted to Velocity actually :)

You'll still have to explain me how you do that magic in velocity, I'd be interested :) I'm talking about the #set($query = $services.query.xwql("").setFilter(and("unique", "hidden"))

BTW on http://en.wikipedia.org/wiki/Fluent_interface#Java their examples shows a usage where they call setParameter several times.

This is also a possibility. We can call setFilter() several times.

Yes, that's the type same chaining as addFilter() - though the name is less correct IMO Jerome

Thanks -Vincent

...

Jerome.

...

Anyway I'm fine with either addFilter or setFilter.

Also +1 to use a QueryFilter for adding a "distinct" in the query.

Thanks -Vincent

...

WDYT ? JV.

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jérôme Velociter Winesquare http://www.winesquare.net/