On Dec 5, 2005, at 2:03 AM, Ray Tsang wrote:
I think this release issue died out again. I noticed an increase in
commit activities recently! I've also noticed the release plan for
2.0 on the wiki. Does current 1.9 already meet the criterias for 2.0?
At least API-wise? If so, is it possible t
Hi
So far I have seen no mention of XPath like queries.
Not that I am a huge fan here, but it would give a standard query
language and standard parser (jaxen saxpath maybe). The disadvantage is
wrapping stuff up as functions, as already discussed. Adding functions
is OK.
E.g.
//*[termQuery(@my:
>From my work in port Lucene to Delphi I think that have a LQL (Lucene Query
Language) is a valuable idea, but I consider that put it in XML is not
expresive enough for this...
Anyway, I think that going the way of SQL or OCL can be better is a more
clear syntax have:
QUERY title,date,size, c
On 12/5/05, Mario Alejandro M. <[EMAIL PROTECTED]> wrote:
> or maybe embeb a Scripting engine? that can be more usefull, and can be used
> for easy extend other things apart of the query language..
I looked into this a year ago... most scripting languages have an
emphasis on script execution speed
Yonik Seeley wrote:
I looked into this a year ago... most scripting languages have an
emphasis on script execution speed, not script parsing speed (which is
what we would need). The scripting languages I tried were horribly
slow at parsing a small script. The only one that could parse at a
rea
BooleanQuery add public method that returns number of clauses this query
Key: LUCENE-476
URL: http://issues.apache.org/jira/browse/LUCENE-476
Project: Lucene - Java
Type: Improvement
Component
[
http://issues.apache.org/jira/browse/LUCENE-476?page=comments#action_12359321 ]
Volodymyr Bychkoviak commented on LUCENE-476:
-
sorry for unfinished description
add public method getClausesCount() to BooleanQuery that returns number of
clauses
[ http://issues.apache.org/jira/browse/LUCENE-476?page=all ]
Volodymyr Bychkoviak updated LUCENE-476:
Attachment: BooleanQuery.diff
> BooleanQuery add public method that returns number of clauses this query
> -
> is a more clear syntax have:
>
> QUERY title,date,size, content WHERE (title LIKE
> 'foo*' OR size>=0)
Let's not forget that unlike most query languages
which are boolean (things either match or they don't)
Lucene has many facilities for influencing the degree
to which matches occur.
A lot of
[
http://issues.apache.org/jira/browse/LUCENE-476?page=comments#action_12359326 ]
Yonik Seeley commented on LUCENE-476:
-
Perhaps it would be better to either support returning a Collection view of the
BooleanQuery, or have BooleanQuery directly implemen
I think that BooleanQuery should not implement Collection directly,
because it contains only BooleanClause's objects.
Collection view is good idea. I think it should be unmodifiable view.
public Collection clauses() {
return Collections.unmodifiableCollection(clauses);
}
Yonik Seeley (
On Monday 05 December 2005 17:56, John Haxby wrote:
> Yonik Seeley wrote:
>
> >I looked into this a year ago... most scripting languages have an
> >emphasis on script execution speed, not script parsing speed (which is
> >what we would need). The scripting languages I tried were horribly
> >slow
Since Lucene 1.9 is a long-awaited release where we're considering deprecating
some APIs, how about renaming and deprecating IndexReader.delete() as follows:
- IndexReader.delete(int) -> IndexReader.deleteDocument(int)
- IndexReader.delete(Term) -> IndexReader.deleteDocuments(Term)
There a
On Dec 5, 2005, at 3:18 PM, Paul Elschot wrote:
On Monday 05 December 2005 17:56, John Haxby wrote:
Yonik Seeley wrote:
I looked into this a year ago... most scripting languages have an
emphasis on script execution speed, not script parsing speed
(which is
what we would need). The scriptin
On Montag 05 Dezember 2005 21:04, Andi Vajda wrote:
> - IndexReader.deleteDocument(int) deletes the ONE document behind the
> docid passed in.
> - IndexReader.deleteDocuments(Term) deletes ALL documents containing
> the term passed in.
Yes, I like those names better than the current ones.
On Dec 5, 2005, at 3:04 PM, Andi Vajda wrote:
Since Lucene 1.9 is a long-awaited release where we're considering
deprecating some APIs, how about renaming and deprecating
IndexReader.delete() as follows:
- IndexReader.delete(int) -> IndexReader.deleteDocument(int)
- IndexReader.delete(Te
Erik's scenario pretty much nails it for me.
I prefer the Ant-like XML approach over a Spring one because all the
messy classnames are removed from document instances. ( I wasn't
suggesting we use either technology, merely citing them as object
assembly languages). Haven't seen HiveMind/Digest
On Monday 05 December 2005 23:36, Erik Hatcher wrote:
> On Dec 5, 2005, at 3:18 PM, Paul Elschot wrote:
..
> >
> > boosting:
> > match:
> > moreLikeThis(percent="0.25", docId="44"):
> > compareField("contents")
> > compareField("title")
> > downgrade(demote="0.5"):
> > simpl
On Dec 5, 2005, at 5:36 PM, Erik Hatcher wrote:
While there have been several different topics brought up on this
thread, it seems we're diverging from the original idea. Let's
consider the most basic use case example here, and I'm making it
intentionally as concrete as possible:
A Swing
[ http://issues.apache.org/jira/browse/LUCENE-248?page=all ]
Yonik Seeley resolved LUCENE-248:
-
Fix Version: 1.9
Resolution: Fixed
Assign To: Yonik Seeley (was: Lucene Developers)
fixed a constructor bug, tweaked javadoc, added a simple
On 12/5/05, Erik Hatcher <[EMAIL PROTECTED]> wrote:
> Having an XML format representing a Query
> and a mechanism to parse it into an actual Query instance makes a lot
> of sense.
Certainly. A representation is needed where it is very easy to add
support for new queries, flexible enough to handle
> If we go with XML, I think this must be solved (or else we are at the
> point where we can only represent a subset of queries that lucene can
> handle again).
Hmmm, maybe it's not quite so serious if the XML represents a
pre-analyzed query vs post-analyzed.
This doesn't appear quite as simple a
I'm extremely stoked to see this topic come up, but very sad that I didn't
have time to read any Lucene mail this past weekend. I'll have to
catchup.
First off...
: Again, we're talking machine-to-machine communication here, not human-
: machine.
: While there have been several different topic
Hopefully that makes sense to someone besides just me. It's
certainly a
lot more complexity then a simple one to one mapping, but it seems
to me
like the flexability is worth spending the extra time to design/
build it.
Makes perfect sense to me, and it doesn't seem any more complex tha
Hopefully that makes sense to someone besides just me. It's
certainly a
lot more complexity then a simple one to one mapping, but it seems
to me
like the flexability is worth spending the extra time to design/
build it.
Makes perfect sense to me, and it doesn't seem any more complex
: Though, I'd be careful with proposing a variety of equivalent
: syntaxes as it may easily lead to more confusion than good. Let's
: start with one canonical syntax. If desired, other (more pleasant)
: syntaxes may then be converted to that as part of a preprocessing step.
Experience has taught
26 matches
Mail list logo
