From users-return-19486-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Feb 26 14:22:51 2013 Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C6A1FE35D for ; Tue, 26 Feb 2013 14:22:51 +0000 (UTC) Received: (qmail 92814 invoked by uid 500); 26 Feb 2013 14:22:51 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 92710 invoked by uid 500); 26 Feb 2013 14:22:50 -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 92697 invoked by uid 99); 26 Feb 2013 14:22:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2013 14:22:49 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of erefer@gmail.com designates 209.85.212.180 as permitted sender) Received: from [209.85.212.180] (HELO mail-wi0-f180.google.com) (209.85.212.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2013 14:22:43 +0000 Received: by mail-wi0-f180.google.com with SMTP id hi8so4713485wib.1 for ; Tue, 26 Feb 2013 06:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=W1K36NVfX8YTCH8KjitfFSMl0VOaH/MqfNX4Z8RPtTY=; b=gERqZHotqy3Z0+DMluBF4YE1b/LYyHLOXvSiwNWH9mdwaA3VTBZ345zwBr7mmVJ2Vc sHQ3LMXtUk2/LEkMXNWTlCg4JkcTUOFQJcgw7t2Bhv7+yqLSLsa/hNm1clvo9DcNjZ+y dPio2npqhGVaNmEbkZDjRaJnjsDprsCobskJXA2HF2NaT063uKVjr+IjKQnXIG34aCIn yIEGPDGKbPaKMSiekvcFwpUrzTCFcrLtDTX9E4zCF2KeeZstGF2nVokp9so2gFxWZCHQ vGuxf6+sgRnJhEghWSvIEmAqKy7F1ifxZGXEp3+esxpUPqCS24KUnmTptmxO5NT43WdO q1lQ== MIME-Version: 1.0 X-Received: by 10.194.9.166 with SMTP id a6mr11671893wjb.2.1361888542154; Tue, 26 Feb 2013 06:22:22 -0800 (PST) Received: by 10.194.28.99 with HTTP; Tue, 26 Feb 2013 06:22:22 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 15:22:22 +0100 Message-ID: Subject: Fwd: Strange fulltext search behaviour From: rfr To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hello again! It seams that I made a mistake in my evaluation. The problem seems to be linked when the slash is followed by a series of letters only. It means my query works for: M/AB2/.... L/A11/... but not for L/ABC... M/ZTS... I came across some messages on the internet regarding lucene/solr and slashes but I have absolutely no idea on how I could solve this problem... ---------- Forwarded message ---------- From: rfr Date: Tue, Feb 26, 2013 at 2:16 PM Subject: Strange fulltext search behaviour To: users@jackrabbit.apache.org Hello! In our application, some nodes have "record numbers" in the form [A-Z]/([A-Z]|[0-9])+/[0-9]{9} For exemple: N/620/000002032 M/AKA/000000235 or L/AMA/0000000100 If I perform a full text search on this values, the search find my nodes. If i try a search like N/*2032 or M/AK*235, I'm also able to retrieve my nodes. But for an unknown reason, if I search for L/* or even L/AMA/000000?00, the system does not find any node and seems to not even search for something. The record number is stored in a string property and I'm sure the nodes are indexed since other queries on the same nodes works for other search tokens. It is like the "L/..." format is causing some troubles to the indexer or the search code. Any pointers? Can someone test this behaviour to see if it is reproductible? Thanks a lot! Regards, Fred