jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Parvulescu <alex.parvule...@gmail.com>
Subject Re: limiting the selectors in the select list
Date Mon, 12 Dec 2011 10:20:56 GMT
Hi Lukas,

This is how jackrabbit does it:

        StringBuilder join = new StringBuilder(
                "SELECT a.* FROM [nt:unstructured] AS a");
        join.append("  INNER JOIN [nt:unstructured] AS b ON b.[jcr:uuid] =
a.testref ");

        QueryResult result = qm.createQuery(join.toString(),
Query.JCR_SQL2).execute();
        System.out.println(Arrays.toString(result.getSelectorNames())); //
-> [a, b]
        System.out.println(Arrays.toString(result.getColumnNames())); // ->
[a.jcr:primaryType]
        for (Row row : JcrUtils.getRows(result)) {
            System.out.println("a: " + row.getNode("a").getPath());  // "a"
related info is there
            System.out.println("b: " + row.getNode("b").getPath());  // "b"
is also present in the returned result set
        }


So, you are right you'll always get the full selector content is returned
in a row (both "a" and "b" in this case), but 'getColumnNames' will tell
you what was in the 'SELECT' specifically.
I don't know if this should be considered extra weight on the remoting
layer, and what would be the gain of filtering out unneeded selector info
before pushing the info over the wire.

Back to your example, I don't understand why you would want to know what
was the default selector, as you are the one building the sql in the first
place. So you probably know that you are looking for "data.*" .

best,
alex


On Fri, Dec 9, 2011 at 9:11 PM, Lukas Kahwe Smith <mls@pooteeweet.org>wrote:

>
> On Dec 9, 2011, at 12:10 , Lukas Kahwe Smith wrote:
>
> >
> > On Dec 9, 2011, at 11:54 , Lukas Kahwe Smith wrote:
> >
> >> Hi,
> >>
> >> I am wondering if this is a bug or a feature.
> >>
> >> I have a query with a join. notice the SELECT data.*
> >>
> >> SELECT
> >>   data.*
> >> FROM
> >>   [nzz:unstructured] AS data
> >>   LEFT OUTER JOIN [nzz:unstructured] AS referring ON
> referring.reference = data.[jcr:uuid]
> >> WHERE
> >>       (referring.reference IS NOT NULL AND ISDESCENDANTNODE(referring,
> '/article/2011/12/08'))
> >>       OR
> >>       ISDESCENDANTNODE(data, '/article/2011/12/08')
> >>
> >>
> >> But I actually end up with rows like the following, aka 'referring' is
> still listed.
> >
> >
> > ok via davex I get
> >
> > <D:multistatus xmlns:D="DAV:">
> >  <D:response>
> >    <D:href>
> http://localhost:8080/server/foo/jcr%3aroot/article/2011/12/08/N_J4252/
> </D:href>
> >    <D:propstat>
> >      <D:prop>
> >        <dcr:search-result-property xmlns:dcr="
> http://www.day.com/jcr/webdav/1.0">
> >          <dcr:column>
> >            <dcr:name>data.jcr:primaryType</dcr:name>
> >            <dcr:value dcr:type="Name">nt:unstructured</dcr:value>
> >          </dcr:column>
> >          <dcr:column>
> >            <dcr:name>jcr:path</dcr:name>
> >            <dcr:value
> dcr:type="Path">/article/2011/12/08/N_J4252</dcr:value>
> >            <dcr:selectorName>data</dcr:selectorName>
> >          </dcr:column>
> >          <dcr:column>
> >            <dcr:name>jcr:score</dcr:name>
> >            <dcr:value dcr:type="Double">6.761604309082031</dcr:value>
> >            <dcr:selectorName>data</dcr:selectorName>
> >          </dcr:column>
> >          <dcr:column>
> >            <dcr:name>jcr:path</dcr:name>
> >            <dcr:selectorName>referring</dcr:selectorName>
> >          </dcr:column>
> >          <dcr:column>
> >            <dcr:name>jcr:score</dcr:name>
> >            <dcr:value dcr:type="Double">0.0</dcr:value>
> >            <dcr:selectorName>referring</dcr:selectorName>
> >          </dcr:column>
> >        </dcr:search-result-property>
> >      </D:prop>
> >      <D:status>HTTP/1.1 200 OK</D:status>
> >    </D:propstat>
> >  </D:response>
> >
> > Does anyone have a hint how this is handled inside the Java JCR API?
> > Is there some iterator that lets you filter by selector or is this
> something the user has to implement himself?
>
> continuing my monolog.
> i guess i can determine the default selector from "data.jcr:primaryType"
> so in this case the default selector would be "data"
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message