You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Paco Avila <pa...@git.es> on 2007/02/02 12:40:16 UTC

bug in SQL CONTAINS?

I think that these queries equivalents:

XPATH: //element(*, okm:document)[jcr:contains(okm:content, 'naranjas')]

and

SQL: SELECT * FROM okm:document WHERE CONTAINS(okm:content, 'naranjas')

But the XPATH one works and the SQL doesn't return anything.

-- 
GIT Consultors S.L.
c\ Francesc Rover 2-B
07003 Palma de Mallorca
(Illes Balears)

Re: bug in SQL CONTAINS?

Posted by Marcel Reutegger <ma...@gmx.net>.
Paco Avila wrote:
> El lun, 05-02-2007 a las 09:11 +0100, Marcel Reutegger escribió:
>> Paco Avila wrote:
>>> I think that these queries equivalents:
>>>
>>> XPATH: //element(*, okm:document)[jcr:contains(okm:content, 'naranjas')]
>>>
>>> and
>>>
>>> SQL: SELECT * FROM okm:document WHERE CONTAINS(okm:content, 'naranjas')
>>>
>>> But the XPATH one works and the SQL doesn't return anything.
>> Those two queries are not equivalent. okm:content in the XPath case refers to 
>> the name of a node, whereas in SQL okm:content by definition refers to a property.
>>
>> Only when you use XPath you can define whether a path refers to a node or a 
>> property using the @ (attribute axis). There's no such facility in SQL, 
>> therefore a relative path in a contains function always references a property.
>>
>> But I'm open to suggestions how the XPath query could be mapped to SQL.
> 
> So, actually there is no SQL equivalent for this XPATH query?

correct.

regards
  marcel

Re: bug in SQL CONTAINS?

Posted by Paco Avila <pa...@git.es>.
El lun, 05-02-2007 a las 09:11 +0100, Marcel Reutegger escribió:
> Paco Avila wrote:
> > I think that these queries equivalents:
> > 
> > XPATH: //element(*, okm:document)[jcr:contains(okm:content, 'naranjas')]
> > 
> > and
> > 
> > SQL: SELECT * FROM okm:document WHERE CONTAINS(okm:content, 'naranjas')
> > 
> > But the XPATH one works and the SQL doesn't return anything.
> 
> Those two queries are not equivalent. okm:content in the XPath case refers to 
> the name of a node, whereas in SQL okm:content by definition refers to a property.
> 
> Only when you use XPath you can define whether a path refers to a node or a 
> property using the @ (attribute axis). There's no such facility in SQL, 
> therefore a relative path in a contains function always references a property.
> 
> But I'm open to suggestions how the XPath query could be mapped to SQL.

So, actually there is no SQL equivalent for this XPATH query?
-- 
GIT Consultors S.L.
c\ Francesc Rover 2-B
07003 Palma de Mallorca
(Illes Balears)

Re: bug in SQL CONTAINS?

Posted by Marcel Reutegger <ma...@gmx.net>.
Paco Avila wrote:
> I think that these queries equivalents:
> 
> XPATH: //element(*, okm:document)[jcr:contains(okm:content, 'naranjas')]
> 
> and
> 
> SQL: SELECT * FROM okm:document WHERE CONTAINS(okm:content, 'naranjas')
> 
> But the XPATH one works and the SQL doesn't return anything.

Those two queries are not equivalent. okm:content in the XPath case refers to 
the name of a node, whereas in SQL okm:content by definition refers to a property.

Only when you use XPath you can define whether a path refers to a node or a 
property using the @ (attribute axis). There's no such facility in SQL, 
therefore a relative path in a contains function always references a property.

But I'm open to suggestions how the XPath query could be mapped to SQL.

regards
  marcel