Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 86908 invoked from network); 25 Apr 2006 13:31:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 Apr 2006 13:31:52 -0000 Received: (qmail 42580 invoked by uid 500); 25 Apr 2006 13:30:48 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 42287 invoked by uid 500); 25 Apr 2006 13:30:46 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 42277 invoked by uid 99); 25 Apr 2006 13:30:46 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Apr 2006 06:30:46 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [213.56.215.224] (HELO gateway.nuxeo.com) (213.56.215.224) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Apr 2006 06:30:45 -0700 Received: from [192.168.2.8] (firefly.in.nuxeo.com [192.168.2.8]) by gateway.nuxeo.com (Postfix) with ESMTP id E0DDF1DDCD for ; Tue, 25 Apr 2006 15:30:27 +0200 (CEST) Message-ID: <444E246E.1050707@nuxeo.com> Date: Tue, 25 Apr 2006 15:30:22 +0200 From: Florent Guillaume User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: efficient note type indexing References: <4898018E-C69A-4302-9065-5CB61ECA21A5@nuxeo.com> <4445F6E7.4060807@gmx.net> <444CD777.8000401@nuxeo.com> <444DEA55.1080507@gmx.net> In-Reply-To: <444DEA55.1080507@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Marcel Reutegger wrote: > Florent Guillaume wrote: >>> using different types for the child nodes is definitively a good >>> idea, as it helps narrowing down the set of nodes that may match. >> >> If I have the (non-mixin) types: >> [my:bar] >> ... >> [my:foo] > my:bar >> ... >> [my:gee] > my:bar >> ... >> the spec (6.6.3.2) tells me that I can query >> //element(*, my:bar) >> and I'll get my:foo and my:gee nodes too. But is this implemented in >> jackrabbit using efficient indexes, or is there an iteration and >> comparison going on? > > jackrabbit uses an index to resolve the types. it basically expands the > type hierarchy on parse time and then uses the index to collect the node. Ah excellent, thanks. That's what I hoped. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com