Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of crankydillo@gmail.com
 designates 209.85.216.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=H685S1NQcH5iyWY9uzb+A2Ng7ACgq+ver8BJb2GykwTXsbGWPVB/mwvRVQdALqRS58
         e8fuT+Fhtjby3vLuDnouO9vNXwbtr4XZtUz4k7+MbEge19weyU+6QCjWfZ9/96ZXsd64
         AV2I6H6AY9xaBZbTvmzj4N3pIkBO4saxZU+pk=
MIME-Version: 1.0
In-Reply-To: <AANLkTimxQC-1UkOvhVKUN4H25e75eK4nuXgPMvyyMac1@mail.gmail.com>
References: <AANLkTimcOGVH73Exq-1+3+f1_rjkdH1=Wgx_VrhqmTNW@mail.gmail.com>
	<AANLkTimxQC-1UkOvhVKUN4H25e75eK4nuXgPMvyyMac1@mail.gmail.com>
Date: Mon, 28 Mar 2011 13:58:10 -0500
Message-ID: <BANLkTin-YKoVxahAXgg3LMZQdDmzO-Rk9A@mail.gmail.com>
Subject: Re: jcr:like on long string properties (Jackrabbit 1.6.1)
From: Samuel Cox <crankydillo@gmail.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

First, I just tried with Jackrabbit and got the same result.
Basically, using jcr:like as part of a xpath query is not working for
long string properties.  I have the following Scala app written for
testing.  I can port to Java if necessary..

import javax.jcr._
import org.apache.jackrabbit.core.TransientRepository

object Searcher {
  def main(args: Array[String]): Unit =3D {
    val repo =3D new TransientRepository();
    val session =3D repo.login(new SimpleCredentials("f", Array('p')));
    try {

      val root =3D session.getRootNode;
      val node =3D root.addNode("anode");
      node.setProperty("ls", ("a" * 10000) + "bcd");
      node.setProperty("ss", "aaabcd");

      session.save();

      val searcher =3D new Searcher(session);

      // Expect this to return sequence with 1 element.
      val res =3D searcher.xpath(".[jcr:like(@ss, \"%bc%\")]");
      println(res.size)  // and it does

      // Expect this to return sequence with 1 element.
      val res2 =3D searcher.xpath(".[jcr:like(@ls, \"%bc%\")]");
      println(res2.size)  // but it does not
    } finally {
      session.logout();
    }
  }
}

import javax.jcr.{Node, NodeIterator, Session}
import javax.jcr.version.Version
import javax.jcr.query.Query.XPATH;

/**
* A facade for querying Jackrabbit.
*
* @author scox
*/
class Searcher(session: Session) {

  implicit def nodeIter2Iter(
      i: NodeIterator
    ) =3D new Iterator[Node] {
    def next =3D i.nextNode;
    def hasNext =3D i.hasNext;
    def remove =3D i.remove;
  }


  lazy val queryMgr =3D session.getWorkspace.getQueryManager

  def xpath(xpath: String): Seq[Node] =3D {
    val query =3D queryMgr.createQuery(xpath, XPATH);
    val result =3D query.execute;
    val iter =3D result.getNodes;
    iter.toSeq
  }
}


On Mon, Mar 28, 2011 at 1:21 PM, Jeroen Reijn <j.reijn@onehippo.com> wrote:
> Hi Samuel,
>
> could you describe what is not working? As far as I know this should work
> for any string, but it might have to do with the query or the stored valu=
es.
>
> Regards,
>
> Jeroen
>
> On Wed, Feb 23, 2011 at 4:40 PM, Samuel Cox <crankydillo@gmail.com> wrote=
:
>
>> Hi,
>>
>> I have been operating under the assumption that I could use jcr:like
>> to in effect do a substring search across string properties. =A0This
>> worked well for all my test cases. =A0The problem is that the real data
>> has strings that are much longer than my test data (bad test data:).
>> Anyhow, should this not work for any length string? =A0I realize the
>> performance is bad, but we don't anticipate this search crossing
>> thousands and thousands of nodes.
>>
>> Here is a sample xpath:
>>
>>
>> jcr:system/jcr:versionStorage/_x0036_c/_x0038_6/cb/_x0036_c86cb58-74a9-4=
955-b4a5-6b19eb6469f2/_x0031_.14//pvsw:artifact[jcr:like(pvsw:data/@pvsw:co=
ntents,
>> '%EDI%')]
>>
>> I'm going to try upgrading to 1.6.4 now.
>>
>> Any help is greatly appreciated.
>>
>