Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 97192 invoked from network); 29 Nov 2010 15:49:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 29 Nov 2010 15:49:02 -0000 Received: (qmail 53598 invoked by uid 500); 29 Nov 2010 15:49:01 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 53492 invoked by uid 500); 29 Nov 2010 15:49:01 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 53478 invoked by uid 99); 29 Nov 2010 15:49:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Nov 2010 15:49:01 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jzitting@adobe.com designates 64.18.1.29 as permitted sender) Received: from [64.18.1.29] (HELO exprod6og112.obsmtp.com) (64.18.1.29) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Nov 2010 15:48:50 +0000 Received: from source ([192.150.8.22]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTPPLTD9ePr9sLeJocgihNt4rzAzjt8gk@postini.com; Mon, 29 Nov 2010 07:48:29 PST Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oATFmQVV012038 for ; Mon, 29 Nov 2010 07:48:27 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oATFmPtm012647 for ; Mon, 29 Nov 2010 07:48:25 -0800 (PST) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 29 Nov 2010 07:48:25 -0800 Received: from jzitting.dev.day.com (10.131.197.63) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.2.254.0; Mon, 29 Nov 2010 15:48:23 +0000 Message-ID: <4CF3CB44.6010700@adobe.com> Date: Mon, 29 Nov 2010 16:48:20 +0100 From: Jukka Zitting Organization: Adobe User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: "users@jackrabbit.apache.org" Subject: Re: Functionality to store indexes in database with jackrabbit 2.1.2 or upcoming releases......... References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, Great discussion! I've recently started looking at ways to implement the "search collection" stuff Alex referred to, and it would be great if this discussion could end up helping design such an implementation. We should move to dev@ for the details. On 29/11/10 14:21, Ard Schrijvers wrote: > For example mandatad behaviour according spec: > > //*[@jcr:contains(.,'jcr')] > > must return *all* nodes in the current workspace that contain jcr. > This effectively mandates that the entire thing can be searched as a > 'single' index. By the spec the above query could just as well be implemented by a tree traversal, just like the SQL standard makes no demands on where and how RDBMs uses indexes. What I'd like to see is an equivalent of the CREATE INDEX statement that could be used to add JCR indexes that selectively boost the performance of the kinds of searches that a specific deployment is relying on. PS. Regarding index-in-JCR, nowadays with a file-based data store a Lucene search index stored and accessed as JCR nodes and properties should be pretty efficient... BR, Jukka Zitting