You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Michael Shoener <ms...@softwareapps.net> on 2009/10/08 23:05:03 UTC
Custom node or mixin added to existing node
I am trying to figure out the best way to store my custom metadata in our
repository.
In our application we want to allow users to create custom named tag/value
pairs that will get stored with the document in the repository as
properties.
I have tried using a mixin but when searching I have to search on my mixin
type not the nt:resource (which contains the binary data) because the
nt:resource does not contain my custom property values and they don't get
returned with the query. But when I do that I can't query the binary content
of the node because my query is searching against my custom mixin type I
created.
Do I need to define a custom node type that extends nt:resource and allow
arbitrary property value (if this is even possible).
Any help would be appreciated.
Best Regards,
Michael Shoener
Support Staff
Software Application Services, Inc.
Re: Custom node or mixin added to existing node
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Oct 9, 2009 at 23:19, Michael Shoener <ms...@softwareapps.net> wrote:
> So if I create a custom mixin and apply it to the "nt:file" node, and then
> do the following query:
>
> //element(*,hfs:fileInfo)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description, 'testing')]
>
> It will return all of the nodes where the binary content matches my search
> term or the "hfs:description" property value matches the search term.
>
> Is this correct?
Yes. I'd recommend to actually play and test with it, so you might get
a sense for the best solution for you.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
RE: Custom node or mixin added to existing node
Posted by Michael Shoener <ms...@softwareapps.net>.
So if I create a custom mixin and apply it to the "nt:file" node, and then
do the following query:
//element(*,hfs:fileInfo)[jcr:contains(jcr:content, 'testing') or
jcr:contains(@hfs:description, 'testing')]
It will return all of the nodes where the binary content matches my search
term or the "hfs:description" property value matches the search term.
Is this correct?
Best Regards,
Michael Shoener
Support Staff
Software Application Services, Inc.
-----Original Message-----
From: Alexander Klimetschek [mailto:aklimets@day.com]
Sent: Friday, October 09, 2009 11:55 AM
To: users@jackrabbit.apache.org
Subject: Re: Custom node or mixin added to existing node
On Fri, Oct 9, 2009 at 16:20, Michael Shoener <ms...@softwareapps.net>
wrote:
> But the problem with the following query:
>
> //element(*,hfs:fileInfo)[jcr:contains(., 'testing') or
> jcr:contains(@hfs:description, 'testing')]
>
> Is that is searches on the entire node, not just the file contents and
> my specified property. I would like to only search on specific
> properties and the file contents, not the entire node. I would like to
> keep the meta data separate from the actual file contents. So do I
> create a mixin and add that to the "nt:file" parent node of the
> "nt:resource" node that holds the actual binary file data? If so then do I
query against my custom mixin type?
This query assumes the mixin to be set on the jcr:content node (with primary
resource type nt:resource), as you noted for your first query.
> Also, I thought in order to have the property returned, whether it
> contained the term being searched or not, I had to put the
> /(hfs:description |
> hfs:anotherpropertyname) at the end of the query. Is that incorrect then?
The result always consists of the full node. Just specifying the property
you'll access doesn't make it faster.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Custom node or mixin added to existing node
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Oct 9, 2009 at 16:20, Michael Shoener <ms...@softwareapps.net> wrote:
> But the problem with the following query:
>
> //element(*,hfs:fileInfo)[jcr:contains(., 'testing') or
> jcr:contains(@hfs:description, 'testing')]
>
> Is that is searches on the entire node, not just the file contents and my
> specified property. I would like to only search on specific properties and
> the file contents, not the entire node. I would like to keep the meta data
> separate from the actual file contents. So do I create a mixin and add that
> to the "nt:file" parent node of the "nt:resource" node that holds the actual
> binary file data? If so then do I query against my custom mixin type?
This query assumes the mixin to be set on the jcr:content node (with
primary resource type nt:resource), as you noted for your first query.
> Also, I thought in order to have the property returned, whether it contained
> the term being searched or not, I had to put the /(hfs:description |
> hfs:anotherpropertyname) at the end of the query. Is that incorrect then?
The result always consists of the full node. Just specifying the
property you'll access doesn't make it faster.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
RE: Custom node or mixin added to existing node
Posted by Michael Shoener <ms...@softwareapps.net>.
But the problem with the following query:
//element(*,hfs:fileInfo)[jcr:contains(., 'testing') or
jcr:contains(@hfs:description, 'testing')]
Is that is searches on the entire node, not just the file contents and my
specified property. I would like to only search on specific properties and
the file contents, not the entire node. I would like to keep the meta data
separate from the actual file contents. So do I create a mixin and add that
to the "nt:file" parent node of the "nt:resource" node that holds the actual
binary file data? If so then do I query against my custom mixin type?
Also, I thought in order to have the property returned, whether it contained
the term being searched or not, I had to put the /(hfs:description |
hfs:anotherpropertyname) at the end of the query. Is that incorrect then?
Best Regards,
Michael Shoener
Support Staff
Software Application Services, Inc.
-----Original Message-----
From: Alexander Klimetschek [mailto:aklimets@day.com]
Sent: Friday, October 09, 2009 10:05 AM
To: users@jackrabbit.apache.org
Subject: Re: Custom node or mixin added to existing node
On Fri, Oct 9, 2009 at 15:38, Michael Shoener <ms...@softwareapps.net>
wrote:
> Ok. I'll give an example of my query. In this example the
> "hfs:fileInfo" is a mixin that was added to the "jcr:content" node
> (which is an nt:resource node type).
>
> //element(*,hfs:fileInfo)[jcr:contains(jcr:content, 'testing')
> or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
>
> The above for some reason does not check the actual contents of
> the file, it only checks my custom property @hfs:description.
First of all, leave out the last location step "/(@hfs:description)" - it
doesn't make a difference.
Secondly, the //element(*,hfs:fileInfo) step will select the jcr:content
node, hence the jcr:contains in the constraint part
([...]) will look for yet another subnode jcr:content. You should change it
to ".":
//element(*,hfs:fileInfo)[jcr:contains(., 'testing') or
jcr:contains(@hfs:description, 'testing')]
> Then I tried querying the "nt:resource" nodes like below, but it then
> does not return my custom mixin property values (I believe it gave me
> an error when trying to retrieve the custom properties defined because
> it only returned "nt:resource" node types).
>
> //element(*,nt:resource)[jcr:contains(jcr:content, 'testing')
> or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
Same issue with jcr:contains as above plus this one will also select all
nt:resource nodes without your custom mixin set and without the
hfs:description property - hence the error.
> Then I created my own custom node type (hfs:file) which extends the
> "nt:file" node type. Then when I queried on that node type it returns
> the results correctly (meaning it searched both my custom property and
> the binary file contents.
>
> //element(*,hfs:file)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
Yes, that's because now element() part selects the file node, and the
jcr:contains now has the correct relative path.
> Now what I need clarification on is what I am doing by defining my
> custom node type the correct (i.e.. best practice) way to go about
> just adding custom properties needed or should I be using a custom
> defined mixin? And If I should be using a mixin then which node does
> it go on? The "nt:file" or "nt:resource"
You decide ;-) That depends on how you want to handle metadata separately
from jcr:content or not (ie. if it changes separately from binary data). But
for the beginning putting it into jcr:content is fine.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Custom node or mixin added to existing node
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Oct 9, 2009 at 15:38, Michael Shoener <ms...@softwareapps.net> wrote:
> Ok. I'll give an example of my query. In this example the "hfs:fileInfo" is
> a mixin that was added to the "jcr:content" node (which is an nt:resource
> node type).
>
> //element(*,hfs:fileInfo)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
>
> The above for some reason does not check the actual contents of the
> file, it only checks my custom property @hfs:description.
First of all, leave out the last location step "/(@hfs:description)" -
it doesn't make a difference.
Secondly, the //element(*,hfs:fileInfo) step will select the
jcr:content node, hence the jcr:contains in the constraint part
([...]) will look for yet another subnode jcr:content. You should
change it to ".":
//element(*,hfs:fileInfo)[jcr:contains(., 'testing') or
jcr:contains(@hfs:description, 'testing')]
> Then I tried querying the "nt:resource" nodes like below, but it then does
> not return my custom mixin property values (I believe it gave me an error
> when trying to retrieve the custom properties defined because it only
> returned "nt:resource" node types).
>
> //element(*,nt:resource)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
Same issue with jcr:contains as above plus this one will also select
all nt:resource nodes without your custom mixin set and without the
hfs:description property - hence the error.
> Then I created my own custom node type (hfs:file) which extends the
> "nt:file" node type. Then when I queried on that node type it returns the
> results correctly (meaning it searched both my custom property and the
> binary file contents.
>
> //element(*,hfs:file)[jcr:contains(jcr:content, 'testing') or
> jcr:contains(@hfs:description,'testing')]/(@hfs:description)
Yes, that's because now element() part selects the file node, and the
jcr:contains now has the correct relative path.
> Now what I need clarification on is what I am doing by defining my custom
> node type the correct (i.e.. best practice) way to go about just adding
> custom properties needed or should I be using a custom defined mixin? And
> If I should be using a mixin then which node does it go on? The "nt:file" or
> "nt:resource"
You decide ;-) That depends on how you want to handle metadata
separately from jcr:content or not (ie. if it changes separately from
binary data). But for the beginning putting it into jcr:content is
fine.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
RE: Custom node or mixin added to existing node
Posted by Michael Shoener <ms...@softwareapps.net>.
Ok. I'll give an example of my query. In this example the "hfs:fileInfo" is
a mixin that was added to the "jcr:content" node (which is an nt:resource
node type).
//element(*,hfs:fileInfo)[jcr:contains(jcr:content, 'testing') or
jcr:contains(@hfs:description,'testing')]/(@hfs:description)
The above for some reason does not check the actual contents of the
file, it only checks my custom property @hfs:description.
Then I tried querying the "nt:resource" nodes like below, but it then does
not return my custom mixin property values (I believe it gave me an error
when trying to retrieve the custom properties defined because it only
returned "nt:resource" node types).
//element(*,nt:resource)[jcr:contains(jcr:content, 'testing') or
jcr:contains(@hfs:description,'testing')]/(@hfs:description)
Then I created my own custom node type (hfs:file) which extends the
"nt:file" node type. Then when I queried on that node type it returns the
results correctly (meaning it searched both my custom property and the
binary file contents.
//element(*,hfs:file)[jcr:contains(jcr:content, 'testing') or
jcr:contains(@hfs:description,'testing')]/(@hfs:description)
Now what I need clarification on is what I am doing by defining my custom
node type the correct (i.e.. best practice) way to go about just adding
custom properties needed or should I be using a custom defined mixin? And
If I should be using a mixin then which node does it go on? The "nt:file" or
"nt:resource"
Best Regards,
Michael Shoener
Support Staff
Software Application Services, Inc.
-----Original Message-----
From: Alexander Klimetschek [mailto:aklimets@day.com]
Sent: Friday, October 09, 2009 3:53 AM
To: users@jackrabbit.apache.org
Subject: Re: Custom node or mixin added to existing node
On Thu, Oct 8, 2009 at 23:05, Michael Shoener <ms...@softwareapps.net>
wrote:
> In our application we want to allow users to create custom named
> tag/value pairs that will get stored with the document in the
> repository as properties.
Use nt:unstructured or have a custom node type / mixin with residual
property definitions (* - the heart of unstructuredness).
> I have tried using a mixin but when searching I have to search on my
> mixin type not the nt:resource (which contains the binary data)
> because the nt:resource does not contain my custom property values and
> they don't get returned with the query. But when I do that I can't
> query the binary content of the node because my query is searching
> against my custom mixin type I created.
I don't understand? Why can't you search for the mixin + a jcr:contains
fulltext search?
> Do I need to define a custom node type that extends nt:resource and
> allow arbitrary property value (if this is even possible).
Of course it is! See here http://jackrabbit.apache.org/node-types.html
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Custom node or mixin added to existing node
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Oct 8, 2009 at 23:05, Michael Shoener <ms...@softwareapps.net> wrote:
> In our application we want to allow users to create custom named tag/value
> pairs that will get stored with the document in the repository as
> properties.
Use nt:unstructured or have a custom node type / mixin with residual
property definitions (* - the heart of unstructuredness).
> I have tried using a mixin but when searching I have to search on my mixin
> type not the nt:resource (which contains the binary data) because the
> nt:resource does not contain my custom property values and they don't get
> returned with the query. But when I do that I can't query the binary content
> of the node because my query is searching against my custom mixin type I
> created.
I don't understand? Why can't you search for the mixin + a
jcr:contains fulltext search?
> Do I need to define a custom node type that extends nt:resource and allow
> arbitrary property value (if this is even possible).
Of course it is! See here http://jackrabbit.apache.org/node-types.html
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com