R: problem on oak jcr sql2 query

[Ancona Francesco]

Hi all,

in red answers below.



Thanks in advance

best regards



-Messaggio originale-
Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
Inviato: martedì 28 marzo 2017 13:35
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone 
Oggetto: Re: problem on oak jcr sql2 query



Hi Francesco,



do you have other indexes within your Oak repo ?

No. We haven’t other indexes.

It might be that the query engine selects a different index which only acts on 
[nt:file] nodes.

You can try checking the plan [1] for your query and compare with the [nt:base] 
version.

It might also be useful to enable debug logging for 
org.apache.jackrabbit.oak.query, that will allow you to check the costs 
associated to each index so that it should be easier to eventually tweak the 
index definitions accordingly (note that the query engine selects the index 
with the lowest cost), e.g. you should see something like:

...

cost for solr is 1.4

cost for lucene is 1.2

cost for reference is Infinity

...

We have already activated debug in oak and we noticed that when we use a query 
with the inner join then cost for solr is Infinity and query is not sent to solr



Do you Know if inner join is supported by Oak to use Solr ?



Regards,

Tommaso



[1] :

http://jackrabbit.apache.org/oak/docs/query/query-troubleshooting.html#Query_Plan





Il giorno mar 28 mar 2017 alle ore 12:28 Ancona Francesco < 
francesco.anc...@siav.it> ha scritto:



> We have wrapped oak jcr implementation with our data model, so it's

> not so easy give you our unit test (our sw is not yet open sourece

> :-)) Besides we know the documenti is correctly indexed, cause we see

> it in solr; so you can use any type of pdf: oak manage full text correctly.

>

> Anyway we tried to use a query like this to optimize performance:

> SELECT parent.* FROM [nt:file] AS parent INNER JOIN [nt:resource] AS

> child ON ISCHILDNODE(child,parent) WHERE CONTAINS(child.*, ' company')

> or CONTAINS(parent.*, ' company')

>

> But we saw that index planner doesn't permit solr query (oak doesn't

> use solr for the query). So we can't find words inside content

> (nt:resource)

>

> What is wrong ?

> Why oak doesn't use solr for full text query ?

>

> Thanks in advance,

> best regards

>

> -Messaggio originale-

> Da: Tommaso Teofili [mailto:tomm...@apache.org]

> Inviato: martedì 28 marzo 2017 10:33

> A: oak-dev@jackrabbit.apache.org

> Cc: Diquigiovanni Simone 
> >

> Oggetto: Re: problem on oak jcr sql2 query

>

> Hi Francesco,

>

> Il giorno lun 27 mar 2017 alle ore 08:59 Ancona Francesco <

> francesco.anc...@siav.it> ha scritto:

>

> Sorry.

>

> We are using Oak 1.4.10 and solr 4.10.4

>

> i send you also a pdf example: the searched word is "sezione"

>

>

> attachments do not usually get through the mailing list therefore we

> can't look into it.

>

>

>

> In another document ([nt:file] that doesn't have childs) i'd want

> match only through metadata that contains the word "company"

>

> Actually  i resolved the problem executing a query like this: select

> p.* from [nt:base] as p where .. contains (p.*, "company") or

> contains (p.*, "sezione")

>

> Then i explore (programmatically and after the query response) jcr

> nodes to set only nodes that are [nt:file]

>

> Is it the correct approach ?

>

>

> this can work but it's surely worse in terms of performance as you

> retrieve and skip some docs you don't really need.

> If you can provide the PDF via a link or, better, a unit test we can

> probably help you more effectively.

>

> Regards,

> Tommaso

>

>

>

> Thanks in advance,

> best regards

>

> -Messaggio originale-

> Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com]

> Inviato: venerdì 24 marzo 2017 14:56

> A: oak-dev@jackrabbit.apache.org

> Cc: Diquigiovanni Simone 
> >

> Oggetto: Re: problem on oak jcr sql2 query

>

> It'd be helpful to also know the version of Oak and Solr you're using

> and, possibly, sample content you expect the query to match.

>

> Thanks,

> Tommaso

>

>

> Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller

> > ha scritto:

>

> > Could you post the index definition please?

> >

> >

> > From: Ancona Francesco 
> > >

> > Reply-To: 
> > "oak-dev@jackrabbit.apache.org"

> > >

> > Date: Thursday, 23 March 2017 at 15:19

> > To: "oak-dev@jackrabbit.apache.org" 
> > 

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Manfred Baedke]

hi

and what do we gain with that? except for the fact that api consumers have
to create an Principal instance from a name?
not sure if that makes sense... i'd rather just clarify the API contract
in the javadoc.

angela


You're right. I didn't realize that the intended overload would have the 
same signature.

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Angela Schreiber]

hi

and what do we gain with that? except for the fact that api consumers have
to create an Principal instance from a name?
not sure if that makes sense... i'd rather just clarify the API contract
in the javadoc.

angela

On 04/04/17 14:32, "Davide Giannella"  wrote:

>On 04/04/2017 11:05, Manfred Baedke wrote:
>> Yes, but now we'd break all existing implementations.
>
>True. We could though, create an overload that receives the principal
>and deprecate the other method for the 1.8 timeframe. By 1.10 we delete
>the deprecated method.
>
>D.
>
>

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Manfred Baedke]

On 4/4/2017 2:32 PM, Davide Giannella wrote:

On 04/04/2017 11:05, Manfred Baedke wrote:

Yes, but now we'd break all existing implementations.

True. We could though, create an overload that receives the principal
and deprecate the other method for the 1.8 timeframe. By 1.10 we delete
the deprecated method.

Sensible.

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Davide Giannella]

On 04/04/2017 11:05, Manfred Baedke wrote:
> Yes, but now we'd break all existing implementations. 

True. We could though, create an overload that receives the principal
and deprecate the other method for the 1.8 timeframe. By 1.10 we delete
the deprecated method.

D.

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Manfred Baedke]

Yes, but now we'd break all existing implementations.

On 4/4/2017 11:09 AM, Davide Giannella wrote:

On 03/04/2017 15:49, Michael Dürig wrote:

Confirmed, this is principle name. At least this is what it was built
for in Jackrabbit 2. The string passed is escaped vis
org.apache.jackrabbit.oak.commons.QueryUtils#escapeForQuery

Just for the sake of discussion. Wouldn't it be better to just pass in
the Principal itself and let the QueryBuilder implementation to deal
with all the requirements of the actual QueryBuilder itself? Escaping
and what ever other things it may be fancying of?

D.

Re: What's the contract of QueryBuilder.impersonates(String name)?

[Davide Giannella]

On 03/04/2017 15:49, Michael Dürig wrote:
> Confirmed, this is principle name. At least this is what it was built
> for in Jackrabbit 2. The string passed is escaped vis
> org.apache.jackrabbit.oak.commons.QueryUtils#escapeForQuery

Just for the sake of discussion. Wouldn't it be better to just pass in
the Principal itself and let the QueryBuilder implementation to deal
with all the requirements of the actual QueryBuilder itself? Escaping
and what ever other things it may be fancying of?

D.

Re: Moving to Java 8

[Julian Reschke]

On 2017-04-03 09:19, Michael Dürig wrote:

On 31.03.17 13:29, Julian Reschke wrote:

On 2017-02-15 12:17, Julian Reschke wrote:

Hi there,

I understand that we might not be able to move to Java 8 just yet, but I
felt it would be good to capture information related to this topic in
Jira (so that we can link other related tickets).

So feel free to provide feedback (and include more information) in

https://issues.apache.org/jira/browse/OAK-5664

Best regards, Julian


So far I didn't see anybody unhappy with a move to required Java 8 for
Oak 1.7 (unstable) and Oak 1.8 (once we get there in ~12 months). Thus,
I propose that we actually make the switch now.


+1 for 1.8.



Does anybody thing we need a vote?


No need for a vote IMO, (lazy) consensus here should be sufficient.

Michael


OK. I assigned the ticket to me, and will make the switch later this week.

Best regards, Julian