You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Sa...@innovations.de on 2010/10/11 10:15:33 UTC

Why should nt:resource be a child of nt:file

Hi all,

 

I have a question regarding the structure of my repository. I followed
the suggestions and modelled my files of type "nt:file" and the
jcr:content property of type "nt:resource". The jcr:content node is a
child of nt:file. I have also other properties of type string on the
nt:file node, for example myapp:comment. Now I want to search the
repository for all "files" (that is the file itself and its` content)
that have myapp:comment='someComment' and contain some text in the
content of the nt:resource node. My XPath query looks like:

 

//element(*, nt:base)[@myapp:comment='someComment' and jcr:contains(.,
'someText')]

 

The problem is that the result set is always empty. The result set is
empty because we do not have nodes that have both - a comment attribute
AND a content. My question is: How can I restructure my query so I get
the nodes that have comment AND some text in the content? Or why is the
jcr:content node of nt:file a child node instead of a property? If it
were a property I would not have that problem.

 

Any ideas would be helpful.

 

Thanks in advance,

 

Sascha Theves

 


Re: Why should nt:resource be a child of nt:file

Posted by Ard Schrijvers <a....@onehippo.com>.
On Tue, Oct 12, 2010 at 8:33 AM,  <Sa...@innovations.de> wrote:
>
> Hi,
>
> nobody an idea?

Just wondering where you read that it 'should be' a child of nt:file.
In the cnd it reads something like:

/**
 * This node type may be used to represent the content of a file. In particular,
 * the jcr:content subnode of an nt:file node will often be an nt:resource.
 *
 * @since 1.0
 */
[nt:resource] > mix:mimeType, mix:lastModified, mix:referenceable
  primaryitem jcr:data
  - jcr:data (BINARY) mandatory

It is all about 'may' afacs and it is up to you where you actually put
the nt:resource. You can just add you own nodetype like

[my:file]
+ jcr:content (nt:base) mandatory

now the nt:resource can be a child of my:file

Regards Ard

>
> Cheers
>
> Sascha
>
> -----Ursprüngliche Nachricht-----
> Von: Sascha.Theves@innovations.de [mailto:Sascha.Theves@innovations.de]
> Gesendet: Mo 11.10.2010 12:48
> An: users@jackrabbit.apache.org
> Betreff: AW: Why should nt:resource be a child of nt:file
>
> Hi Stefan,
>
> I have just tested it and it seems that the XPath query works as you suggested but the same query in SQL does not work. I am a little bit confused now because the earlier posts in the new group mentioned that it should not be possible to search "only" in the jcr:content field.
>
> Can somebody clarify the behaviour?
>
> Thanks,
>
> Sascha
>
> -----Ursprüngliche Nachricht-----
> Von: Sascha.Theves@innovations.de [mailto:Sascha.Theves@innovations.de]
> Gesendet: Montag, 11. Oktober 2010 11:55
> An: users@jackrabbit.apache.org
> Betreff: AW: Why should nt:resource be a child of nt:file
>
> Hi Stefan,
>
> thanks for your reply but that is not possible. The query is invalid. Only the dot "." is supported in the jcr:contains() function. See http://jackrabbit.510166.n4.nabble.com/jcr-data-query-question-td518136.html for explantation.
>
> Any other ideas?
>
> Sascha
>
> -----Ursprüngliche Nachricht-----
> Von: Stefan Hagedorn [mailto:nachteilhaft@gmx.de]
> Gesendet: Montag, 11. Oktober 2010 11:37
> An: users@jackrabbit.apache.org
> Betreff: Re: Why should nt:resource be a child of nt:file
>
> Hi Sascha,
>
> I'm not sure, but I think you only need to descent into the jcr:content
> child of nt:file:
>
> //element(*, nt:file)[@myapp:comment='someComment' and
> jcr:contains(./jcr:content,'someText')]
>
> Regards,
> Stefan
>
> On 11.10.2010 10:15, Sascha.Theves@innovations.de wrote:
>> Hi all,
>>
>>
>>
>> I have a question regarding the structure of my repository. I followed
>> the suggestions and modelled my files of type "nt:file" and the
>> jcr:content property of type "nt:resource". The jcr:content node is a
>> child of nt:file. I have also other properties of type string on the
>> nt:file node, for example myapp:comment. Now I want to search the
>> repository for all "files" (that is the file itself and its` content)
>> that have myapp:comment='someComment' and contain some text in the
>> content of the nt:resource node. My XPath query looks like:
>>
>>
>>
>> //element(*, nt:base)[@myapp:comment='someComment' and jcr:contains(.,
>> 'someText')]
>>
>>
>>
>> The problem is that the result set is always empty. The result set is
>> empty because we do not have nodes that have both - a comment attribute
>> AND a content. My question is: How can I restructure my query so I get
>> the nodes that have comment AND some text in the content? Or why is the
>> jcr:content node of nt:file a child node instead of a property? If it
>> were a property I would not have that problem.
>>
>>
>>
>> Any ideas would be helpful.
>>
>>
>>
>> Thanks in advance,
>>
>>
>>
>> Sascha Theves
>>
>>
>>
>>
>
>
>



-- 
Hippo
Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20 522 4466
USA  • San Francisco  185 H Street Suite B  •  Petaluma CA 94952-5100
•  +1 (707) 773 4646
Canada    •   Montréal  5369 Boulevard St-Laurent  •  Montréal QC H2T
1S5  •  +1 (514) 316 8966
www.onehippo.com  •  www.onehippo.org  •  info@onehippo.com

AW: Why should nt:resource be a child of nt:file

Posted by Sa...@innovations.de.
Hi,

nobody an idea?

Cheers 

Sascha

-----Ursprüngliche Nachricht-----
Von: Sascha.Theves@innovations.de [mailto:Sascha.Theves@innovations.de]
Gesendet: Mo 11.10.2010 12:48
An: users@jackrabbit.apache.org
Betreff: AW: Why should nt:resource be a child of nt:file
 
Hi Stefan,

I have just tested it and it seems that the XPath query works as you suggested but the same query in SQL does not work. I am a little bit confused now because the earlier posts in the new group mentioned that it should not be possible to search "only" in the jcr:content field.

Can somebody clarify the behaviour?

Thanks,

Sascha

-----Ursprüngliche Nachricht-----
Von: Sascha.Theves@innovations.de [mailto:Sascha.Theves@innovations.de] 
Gesendet: Montag, 11. Oktober 2010 11:55
An: users@jackrabbit.apache.org
Betreff: AW: Why should nt:resource be a child of nt:file

Hi Stefan,

thanks for your reply but that is not possible. The query is invalid. Only the dot "." is supported in the jcr:contains() function. See http://jackrabbit.510166.n4.nabble.com/jcr-data-query-question-td518136.html for explantation.

Any other ideas? 

Sascha

-----Ursprüngliche Nachricht-----
Von: Stefan Hagedorn [mailto:nachteilhaft@gmx.de] 
Gesendet: Montag, 11. Oktober 2010 11:37
An: users@jackrabbit.apache.org
Betreff: Re: Why should nt:resource be a child of nt:file

Hi Sascha,

I'm not sure, but I think you only need to descent into the jcr:content 
child of nt:file:

//element(*, nt:file)[@myapp:comment='someComment' and 
jcr:contains(./jcr:content,'someText')]

Regards,
Stefan

On 11.10.2010 10:15, Sascha.Theves@innovations.de wrote:
> Hi all,
>
>
>
> I have a question regarding the structure of my repository. I followed
> the suggestions and modelled my files of type "nt:file" and the
> jcr:content property of type "nt:resource". The jcr:content node is a
> child of nt:file. I have also other properties of type string on the
> nt:file node, for example myapp:comment. Now I want to search the
> repository for all "files" (that is the file itself and its` content)
> that have myapp:comment='someComment' and contain some text in the
> content of the nt:resource node. My XPath query looks like:
>
>
>
> //element(*, nt:base)[@myapp:comment='someComment' and jcr:contains(.,
> 'someText')]
>
>
>
> The problem is that the result set is always empty. The result set is
> empty because we do not have nodes that have both - a comment attribute
> AND a content. My question is: How can I restructure my query so I get
> the nodes that have comment AND some text in the content? Or why is the
> jcr:content node of nt:file a child node instead of a property? If it
> were a property I would not have that problem.
>
>
>
> Any ideas would be helpful.
>
>
>
> Thanks in advance,
>
>
>
> Sascha Theves
>
>
>
>



AW: Why should nt:resource be a child of nt:file

Posted by Sa...@innovations.de.
Hi Stefan,

I have just tested it and it seems that the XPath query works as you suggested but the same query in SQL does not work. I am a little bit confused now because the earlier posts in the new group mentioned that it should not be possible to search "only" in the jcr:content field.

Can somebody clarify the behaviour?

Thanks,

Sascha

-----Ursprüngliche Nachricht-----
Von: Sascha.Theves@innovations.de [mailto:Sascha.Theves@innovations.de] 
Gesendet: Montag, 11. Oktober 2010 11:55
An: users@jackrabbit.apache.org
Betreff: AW: Why should nt:resource be a child of nt:file

Hi Stefan,

thanks for your reply but that is not possible. The query is invalid. Only the dot "." is supported in the jcr:contains() function. See http://jackrabbit.510166.n4.nabble.com/jcr-data-query-question-td518136.html for explantation.

Any other ideas? 

Sascha

-----Ursprüngliche Nachricht-----
Von: Stefan Hagedorn [mailto:nachteilhaft@gmx.de] 
Gesendet: Montag, 11. Oktober 2010 11:37
An: users@jackrabbit.apache.org
Betreff: Re: Why should nt:resource be a child of nt:file

Hi Sascha,

I'm not sure, but I think you only need to descent into the jcr:content 
child of nt:file:

//element(*, nt:file)[@myapp:comment='someComment' and 
jcr:contains(./jcr:content,'someText')]

Regards,
Stefan

On 11.10.2010 10:15, Sascha.Theves@innovations.de wrote:
> Hi all,
>
>
>
> I have a question regarding the structure of my repository. I followed
> the suggestions and modelled my files of type "nt:file" and the
> jcr:content property of type "nt:resource". The jcr:content node is a
> child of nt:file. I have also other properties of type string on the
> nt:file node, for example myapp:comment. Now I want to search the
> repository for all "files" (that is the file itself and its` content)
> that have myapp:comment='someComment' and contain some text in the
> content of the nt:resource node. My XPath query looks like:
>
>
>
> //element(*, nt:base)[@myapp:comment='someComment' and jcr:contains(.,
> 'someText')]
>
>
>
> The problem is that the result set is always empty. The result set is
> empty because we do not have nodes that have both - a comment attribute
> AND a content. My question is: How can I restructure my query so I get
> the nodes that have comment AND some text in the content? Or why is the
> jcr:content node of nt:file a child node instead of a property? If it
> were a property I would not have that problem.
>
>
>
> Any ideas would be helpful.
>
>
>
> Thanks in advance,
>
>
>
> Sascha Theves
>
>
>
>


AW: Why should nt:resource be a child of nt:file

Posted by Sa...@innovations.de.
Hi Stefan,

thanks for your reply but that is not possible. The query is invalid. Only the dot "." is supported in the jcr:contains() function. See http://jackrabbit.510166.n4.nabble.com/jcr-data-query-question-td518136.html for explantation.

Any other ideas? 

Sascha

-----Ursprüngliche Nachricht-----
Von: Stefan Hagedorn [mailto:nachteilhaft@gmx.de] 
Gesendet: Montag, 11. Oktober 2010 11:37
An: users@jackrabbit.apache.org
Betreff: Re: Why should nt:resource be a child of nt:file

Hi Sascha,

I'm not sure, but I think you only need to descent into the jcr:content 
child of nt:file:

//element(*, nt:file)[@myapp:comment='someComment' and 
jcr:contains(./jcr:content,'someText')]

Regards,
Stefan

On 11.10.2010 10:15, Sascha.Theves@innovations.de wrote:
> Hi all,
>
>
>
> I have a question regarding the structure of my repository. I followed
> the suggestions and modelled my files of type "nt:file" and the
> jcr:content property of type "nt:resource". The jcr:content node is a
> child of nt:file. I have also other properties of type string on the
> nt:file node, for example myapp:comment. Now I want to search the
> repository for all "files" (that is the file itself and its` content)
> that have myapp:comment='someComment' and contain some text in the
> content of the nt:resource node. My XPath query looks like:
>
>
>
> //element(*, nt:base)[@myapp:comment='someComment' and jcr:contains(.,
> 'someText')]
>
>
>
> The problem is that the result set is always empty. The result set is
> empty because we do not have nodes that have both - a comment attribute
> AND a content. My question is: How can I restructure my query so I get
> the nodes that have comment AND some text in the content? Or why is the
> jcr:content node of nt:file a child node instead of a property? If it
> were a property I would not have that problem.
>
>
>
> Any ideas would be helpful.
>
>
>
> Thanks in advance,
>
>
>
> Sascha Theves
>
>
>
>


Re: Why should nt:resource be a child of nt:file

Posted by Stefan Hagedorn <na...@gmx.de>.
Hi Sascha,

I'm not sure, but I think you only need to descent into the jcr:content 
child of nt:file:

//element(*, nt:file)[@myapp:comment='someComment' and 
jcr:contains(./jcr:content,'someText')]

Regards,
Stefan

On 11.10.2010 10:15, Sascha.Theves@innovations.de wrote:
> Hi all,
>
>
>
> I have a question regarding the structure of my repository. I followed
> the suggestions and modelled my files of type "nt:file" and the
> jcr:content property of type "nt:resource". The jcr:content node is a
> child of nt:file. I have also other properties of type string on the
> nt:file node, for example myapp:comment. Now I want to search the
> repository for all "files" (that is the file itself and its` content)
> that have myapp:comment='someComment' and contain some text in the
> content of the nt:resource node. My XPath query looks like:
>
>
>
> //element(*, nt:base)[@myapp:comment='someComment' and jcr:contains(.,
> 'someText')]
>
>
>
> The problem is that the result set is always empty. The result set is
> empty because we do not have nodes that have both - a comment attribute
> AND a content. My question is: How can I restructure my query so I get
> the nodes that have comment AND some text in the content? Or why is the
> jcr:content node of nt:file a child node instead of a property? If it
> were a property I would not have that problem.
>
>
>
> Any ideas would be helpful.
>
>
>
> Thanks in advance,
>
>
>
> Sascha Theves
>
>
>
>