Re: svn commit: r1375282 - /incubator/lucene.net/trunk/src/core/Util/Parameter.cs
Instead of doing it this way, do NOT create Occur using separate static
fields.
Merge Parameter into Occur (only used there) and create the entire
dictionary once.
Otherwise, you run into risk of the ArgumentException.
If that happens, because this is raised from the static ctor, you'll have
killed the entire app domain.
On Tue, Aug 21, 2012 at 1:19 AM, Itamar Syn-Hershko ita...@code972.comwrote:
This will probably require releasing the core again as well as a new RC...
The spatial module was updated, still doing some integration tests, will
send more updates soon
On Tue, Aug 21, 2012 at 1:14 AM, synhers...@apache.org wrote:
Author: synhershko
Date: Mon Aug 20 22:14:01 2012
New Revision: 1375282
URL: http://svn.apache.org/viewvc?rev=1375282view=rev
Log:
Fixing a possible NRE which can be thrown during a race condition on
accessing allParameters
This is not an air-tight solution, as an ArgumentException can still be
thrown. I don't care much about doing this within a lock as it will never
be a bottleneck.
https://groups.google.com/group/ravendb/browse_thread/thread/a5cf07e80f70c856
Modified:
incubator/lucene.net/trunk/src/core/Util/Parameter.cs
Modified: incubator/lucene.net/trunk/src/core/Util/Parameter.cs
URL:
http://svn.apache.org/viewvc/incubator/lucene.net/trunk/src/core/Util/Parameter.cs?rev=1375282r1=1375281r2=1375282view=diff
==
--- incubator/lucene.net/trunk/src/core/Util/Parameter.cs (original)
+++ incubator/lucene.net/trunk/src/core/Util/Parameter.cs Mon Aug 20 22
:14:01
2012
@@ -39,11 +39,13 @@ namespace Lucene.Net.Util
// typesafe enum pattern, no public constructor
this.name = name;
string key = MakeKey(name);
-
- if (allParameters.ContainsKey(key))
- throw new
System.ArgumentException(Parameter name + key + already used!);
-
- allParameters[key] = this;
+
+ lock (allParameters)
+ {
+ if (allParameters.ContainsKey(key))
+ throw new
System.ArgumentException(Parameter name + key + already used!);
+ allParameters[key] = this;
+ }
}
private string MakeKey(string name)
Re: Endian types
I would assume that you would have to match the java behavior, if only to make sure that the index format matched. On Wed, Jun 20, 2012 at 5:47 PM, Kim Christensen k...@dubex.dk wrote: Hi all, I was looking into porting some Lucene 4x code, and ran into the issue about Big-Endian and Little-Endian. What is the standpoint on this? Always Big-Endian as Java does it? Regards, Kim
RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
As someone from the nhibernate project We stopped following hibernate a while ago, and haven't regretted it We have mire features, less bugs and better code base Sent from my Windows Phone From: Rory Plaire Sent: Thursday, June 30, 2011 19:58 To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? I don't want to drag this out much longer, but I am curious with people who hold the line-by-line sentiment - are you NHibernate users? -r On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght lysag...@hotmail.com wrote: Can I just plug in my bit and say I agree 100% with what Moray has outlined below. If we move away from the line by line port then over time we'll loose out on the momentum that is Lucene and the improvements that they make. It is only if the Lucene.NET community has expertise in search, a deep knowledge of the project and the community can guarantee that the knowledge will survive members coming and going should such a consideration be give. When Lucene.NET has stood on it's feet for a number of years after it has moved out of Apache incubation should consideration be given to abandoning a line by line port. By all means extend and wrap the libraries in .NET equivalents and .NET goodness like LINQ (we do this internally in our company at the moment); but leave the core of the project on a line by line port. Just my tu-pence worth. Kind Regards Noel -Original Message- From: Moray McConnachie Sent: Thursday, June 30, 2011 10:25 AM To: lucene-net-user@lucene.apache.**orglucene-net-u...@lucene.apache.org Cc: lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? I don't think I'm as hard core on this as Neal, but remember: the history of the Lucene.NET project is that all the intellectual work, all the understanding of search, all the new features come from the Lucene Java folks. Theirs is an immensely respected project, and I trust them to add new features that will be well-tested and well-researched, and to have a decent roadmap which I can trust they will execute on. Now I know there's been an influx of capable developers to Lucene.NET who are ready, willing and (I'm going to assume) able to add a lot more value in a generic .NET implementation as they change it. But it'll take a while before I trust a .NET dedicated framework which is significantly diverged from Java in the way I do the line-by-line version. And at what stage is it not just not a line-by-line port, but not a port at all? At the same time, I recognise that if this project is going to continue, and attract good developers, it has to change in this direction. So that said, I can see why a line-by-line port might not be sustainable. And most people don't need it. But most of us using Lucene in production systems do need a system that we can trust and rely on. So let me chime in with someone else's plea, to keep the general structure close to Lucene, to keep the same general objects and inheritance set-up, and to keep the same method names, even if you add other methods and classes to provide additional functionality. ABSOLUTELY the same file formats. End users benefit a lot from a high degree of similarity, with good documentation and help being available from the Java community. Yours, Moray --**--- Moray McConnachie Director of IT+44 1865 261 600 Oxford Analytica http://www.oxan.com -Original Message- From: Granroth, Neal V. [mailto:neal.granroth@**thermofisher.comneal.granr...@thermofisher.com ] Sent: 29 June 2011 20:47 To: lucene-net-user@lucene.apache.**orglucene-net-u...@lucene.apache.org Cc: lucene-net-dev@incubator.**apache.orglucene-net-...@incubator.apache.org Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? This is has been discussed many times. Lucene.NET is not valid, the code cannot be trusted, if it is not a line-by-line port. It ceases to be Lucene. - Neal -Original Message- From: Scott Lombard [mailto:lombardenator@gmail.**comlombardena...@gmail.com ] Sent: Wednesday, June 29, 2011 1:58 PM To: lucene-net-dev@lucene.apache.**org lucene-net-dev@lucene.apache.org; lucene-net-user@lucene.apache.**org lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed? After the large community response about moving the code base from .Net 2.0 to Net 4.0 I am trying to figure out what is the need for a line-by-line port. Starting with Digy's excellent work on the conversion to generics a priority of the 2.9.4g release is the 2 packages would not be interchangeable. So faster turnaround from a java release won't matter to non line-by-line users they will have to wait until the updates are made to the non line-by-line code base. My question is there really a user
Re: [Lucene.Net] Re: Signing Binary Releases
Okay, cool On Mon, Feb 21, 2011 at 11:27 AM, Robert Jordan robe...@gmx.net wrote: On 21.02.2011 05:55, Stefan Bodewig wrote: On 2011-02-20, Robert Jordan wrote: On 20.02.2011 07:49, Stefan Bodewig wrote: If you talk about strong naming assemblies then I don't have any experience how a well designed scheme of sharing the key between several developers might work. As the maintainer of XMLUnit I'd be interested in a good solution myself. Many open source projects are keeping the key pair (*.snk) together with the source code in their repository because the security significance of the key is zero. Given how .NET assembly signing was designed, no one would be able to generate a compatible Lucene.Net assembly from source code w/out having to update assembly references in all projects using Lucene.Net. This is hardly compatible with open source principles and should be avoided. I agree but users have asked for a strong named version of XMLUnit in the past so I was thinking about providing one as alternative. I've seen similar user requests for log4net or NUnit as well. Yes, the last part of my mail was misleading. I was actually proposing to keep Lucene.Net's SNK key together with the source code and to sign the assembly during the build process. Robert
Re: [Lucene.Net] Creating a Strong Named Assembly as part of our release
Please avoid doing that, it would result in two assemblies, built against the same version of lucene.net being unable to operate, since each uses a different snk. See log4net 1.0.9 and 1.0.10 fiasco for how much problems this can cause. On Tue, Feb 22, 2011 at 7:09 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-21, Troy Howard wrote: If we keep the key private, how do we then manage it? Is there a place to store these kinds of resources, where only the committers have access? If this is the route you wanted to go it would be easy to set up an svn area that only committers had read access to. Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
Educate my users? That is hardly my role. They get the benefit of being able to run a patch version without undue hassle. NHibernate 1.x tried to have a secret snk, and that failed pretty miserably On Mon, Feb 21, 2011 at 2:16 PM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-21, Ayende Rahien wrote: There are many situations where you _have_ to have a strong key, or example, gac deployments. In those cases, anything in the chain also have to have strong key. Yes, I knew that. Sorry if I sounded stupid. In most cases I try to avoid the GAC and my personal use-case (XMLUnit) is quite different from Lucene (i.e. it is less likely to end up as a dependency of something that gets deployed to the GAC). Fortunately my opinion is pretty unimportant here anyway 8-) Most OSS in .NET have signed binary releases, and the snk is usually in the source code. Do you educate your users that there is no security promise attached to the strong name in this case? I've always shied away from using strong names in OSS because of the illusion of verified-publisher they provide in such a setup. Thanks Stefan
Re: [Lucene.Net] Re: Signing Binary Releases
There are many situations where you _have_ to have a strong key, or example, gac deployments. In those cases, anything in the chain also have to have strong key. Most OSS in .NET have signed binary releases, and the snk is usually in the source code. On Mon, Feb 21, 2011 at 6:55 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-20, Robert Jordan wrote: On 20.02.2011 07:49, Stefan Bodewig wrote: If you talk about strong naming assemblies then I don't have any experience how a well designed scheme of sharing the key between several developers might work. As the maintainer of XMLUnit I'd be interested in a good solution myself. Many open source projects are keeping the key pair (*.snk) together with the source code in their repository because the security significance of the key is zero. Given how .NET assembly signing was designed, no one would be able to generate a compatible Lucene.Net assembly from source code w/out having to update assembly references in all projects using Lucene.Net. This is hardly compatible with open source principles and should be avoided. I agree but users have asked for a strong named version of XMLUnit in the past so I was thinking about providing one as alternative. I've seen similar user requests for log4net or NUnit as well. Stefan
Re: Site
Off topic, can we get a [Lucene.NET] prefix for messages to the list? On Wed, Feb 16, 2011 at 11:05 PM, Prescott Nasser geobmx...@hotmail.comwrote: Where does that site compile to? The incubator lucene.net site appears to be the older one
Re: IKVM (or rather OpenJDK) License Problem
It would also have drastic affects on other people using Lucene for commercial and OSS projects. On Thu, Jan 27, 2011 at 11:36 AM, Stefan Bodewig bode...@apache.org wrote: Hi, sorry I started this before doing my homework. If we took the IKVM route Lucene.NET's binary distribution could not bundle the OpenJDK derived DLLs. They are licensed as GPL2 + Classpath Exception[1] which is part of the list of explicitly prohibited licenses for ASF distributions[2]. This would mean users had to download the DLL from the IKVM site themselves which sounds pretty inconvient. Stefan [1] http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=License [2] http://www.apache.org/legal/resolved.html#category-x
Re: Proposal Stage: Net Idiomatic Api Version
JetBrains routinely give away licenses for OSS
On Tue, Jan 4, 2011 at 5:53 PM, Prescott Nasser geobmx...@hotmail.comwrote:
I wonder if we could get a free license for open source. A few people have
mentioned that often companies have these provisions.
-Original Message-
From: Peter Mateja peter.mat...@gmail.com
Date: Tue, 4 Jan 2011 15:49:32
To: lucene-net-...@lucene.apache.org
Subject: Re: Proposal Stage: Net Idiomatic Api Version
Resharper http://www.jetbrains.com/resharper/is a fantastic tool for
auto-formatting code to a particular standard. I haven't done a complete
sweep, but it seems that the default settings match the Microsoft
guidelines
closely. It isn't free unfortunately, but if you're a professional .Net
developer it makes life much easier!
Also, I 2nd the Krzysztof book. Excellent reading. I'll dig it out and
give it another scan.
Peter Mateja
peter.mat...@gmail.com
On Fri, Dec 31, 2010 at 6:50 PM, Troy Howard thowar...@gmail.com wrote:
I agree with the suggestion to follow the MS Coding standard. It's a
good general guideline. Specifically, I'd like to follow all
guidelines put forth in the book:
Framework Design Guidelines: Conventions, Idioms, and Patterns for
Reusable .NET Libraries by Krzysztof Cwalina and Brad Abrams
http://amzn.com/0321246756
There's also a lecture that Krysztof gave that's available as a
offline video download here (the streaming version isn't available at
the moment for some reason):
http://download.microsoft.com/download/8/0/8/808412ec-2561-413d-a9e3-5cd47d37d763/FDGNetCast.zip
With regards to the specifics of the API, I think we should try to
bring together the existing forks (Lucere, Lucille, and Aimee.Net) and
attempt to merge them into a single consistent alternative API for
Lucene.Net. They all use similar but slightly different tactics to
.NETify the codebase.
Also, significant community feedback will be necessary before we
proceed to far down that road. We'll have a lot of work ahead of us
just getting up to date releases finished for the 1:1 API port. It's
my opinion though, that these can be separate and parallel development
efforts.
I made a request of the community in the Lucere project mailing list
to respond with ideas about what an ideal .NET API would look like,
and how it would function. Specifically, I was hoping to get
pseudo-code examples of how end users would like to use Lucene. Even
something as simple as:
using(var luceneIndex = new LuceneIndex.Open(C:\foo\bar))
{
var hitDocs = from doc in luceneIndex where
doc.Field[content].Match(foo) select doc;
}
This represents a lot of ideas all in one little code snippet. Maybe
this isn't an ideal API, maybe it is... If we collect a bunch of code
samples from people like this, we can discuss the merits of various
ideas for the API and settle on an ideal way to present the
functionality of the library in a way that will integrate well with
the .NET 3.5/4.0 environment.
I didn't get a lot of responses in the Lucere mailing list but perhaps
the Lucene.Net community will have some ideas. We should probably
cross-post to the lucene-net-user mailing list with a request for
ideas.
Thanks,
Troy
On Fri, Dec 31, 2010 at 1:35 PM, Michael Herndon mhern...@o19s.com
wrote:
*Net Idiomatic Api Version*
*We should probably be looking for with this criteria is readability
getting people familiar with any new code base faster within their own
Idiom. *
*
*
Starting with a proposal that we use the internal Ms coding
guidelines
http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx
for
the idiomatic version, not to make anyone's life miserable or coding
less
enjoyable or anything.
But its already documented, we can easily point to it without having to
write up our own guidelines, and everyone who works inside of .net
should
be
remotely familiar with it, meaning someone can just come in and crank
out
code.
If need be, we let people work on the code base in their own style and
when
they are done working on a particular area, let them reformat it or
just
run
a tool that auto formats code before each release.
I know their is religious wars fought over this stuff, I don't want to
create one. I could be wrong about the above, but what again, the
goals
should be familiarity, comfort, creating a bigger community.
Also uses of core Interfaces, Annotations, Classes where possible.
(What
are some of these that you would like to see other than IDisposable?)
A good book to comb over with the latest edition is the Framework
Design
Guidelines 2nd edition.
*
*
--
Michael Herndon
Memory Leak because of ClosableThreadLocal
The reasoning for this class doesn't hold for .NET, but that is beside the point. There is somewhere in Lucene where this doesn't clean up (specifically, ThreadResources for Term Cache) That results in ClosableThreadLocal.slots filling up. I fixed this by modifying ClosableThreadLocal to use the .NET ThreadLocal class. If you want to keep Lucene on 2.0, you probably would want to implement a better solution, because as it stands, there isn't a good solution for this.
Re: Memory Leak because of ClosableThreadLocal
No, I am using Lucene.NET 2.9.2, and it showed up there. More specifically, I forked it around r48322 On Wed, Dec 15, 2010 at 2:02 PM, Robert Jordan robe...@gmx.net wrote: On 15.12.2010 12:58, Robert Jordan wrote: On 15.12.2010 09:12, Ayende Rahien wrote: The reasoning for this class doesn't hold for .NET, but that is beside the point. There is somewhere in Lucene where this doesn't clean up (specifically, ThreadResources for Term Cache) That results in ClosableThreadLocal.slots filling up. I fixed this by modifying ClosableThreadLocal to use the .NET ThreadLocal class. If you want to keep Lucene on 2.0, you probably would want to implement a better solution, because as it stands, there isn't a good solution for this. This is already fixed in Lucene 2.9.2. Correction: in *Lucene.Net* 2.9.2 :) Robert
Re: Lucere project announcement
The #1 problem with Lucene is that it doesn't implement IDisposable, which make it _very_ awkward to use in .NET On Thu, Nov 11, 2010 at 8:27 PM, Alex Thompson pierogi...@hotmail.comwrote: I think a better pattern than partial classes would be extension methods (like the way LINQ works with IEnumerable). That way the extensions could be in a separate assembly but appear seamless with the core class. I don't like the name Lucere. I think it's too close and will create confusion. It's so close I wonder if the ASF will have something to say about it. -Original Message- From: Prescott Nasser [mailto:geobmx...@hotmail.com] Sent: Thursday, November 11, 2010 9:46 AM To: lucene-net-...@lucene.apache.org Subject: Re: Lucere project announcement There is benefit to making partial classes if we want to extend, but that adds complexity to the conversion and doesn't do one thing to help us get Lucene.Net into more native .net constructs I personally don't even know enough about lucene yet to know where people would want to extend it. Partial classes I think will be a good move once we have a good system in place to convert java to .net and show that we are keeping pace -Original Message- From: Peter Mateja peter.mat...@gmail.com Date: Thu, 11 Nov 2010 17:20:04 To: lucene-net-...@lucene.apache.org Subject: Re: Lucere project announcement I'm a bit concerned that there's going to be a fragmentation of effort surrounding Lucene.Net, Lucere, and Aimee, LINQ to Lucene ( http://linqtolucene.codeplex.com/, though this appears to be dead) causing more confusion than not. I do agree that initially, Lucene.Net should remain a line by line port. As much as the Java idioms pulled into Lucene.Net can be frustrating to work with in the context of standard .Net development, I think it's more important to have something that works now, and works exactly the same as the base Lucene. As discussed ad nauseum in other forums this has several key benefits. That said, I do long for the elegance of recent .Net language constructs and framework features. I've heard discussion of trying to build a .Net layer on top of Lucene.Net. Having dug into the Lucene.Net code a bit, I'd have to say that this will not be an easy task. I'd wager that quite a bit of the desired .Net-ification of Lucene.Net will result from better automated conversion methods, which would really hinge on the direction taken by the Lucene.Net project, not Lucere. One interesting direction to take, might be to transition some of the core classes in Lucene.Net into partial classes, allowing additional additional class tooling outside of the Lucene.Net core project. This is perhaps a naive suggestion, so if anyone has already considered this route, let me know. Peter Mateja peter.mat...@gmail.com On Thu, Nov 11, 2010 at 3:33 AM, Troy Howard thowar...@gmail.com wrote: All, The recent discussions on this mailing list have shown a few things to be true: - Lucene.Net is definitely still a thriving project with strong leadership represented by George and DIGY - The community surrounding the project is vocal, vibrant and filled with ideas and motivation to help - There is a strong interest in seeing Lucene.Net continue as a line-by-line port of Java Lucene: - It's faster and more manageable to make releases because code can be automatically converted - Retains all the excellence of the Java Lucene project - Provides end users with a wealth of existing knowledge and support surrounding the Java Lucene project - There is a strong interest in have a more .Net style port of Lucene - Many users feel using the Java-idiomatic API is unwieldy - There is a desire to see the code take advantage of valuable .Net framework features that do not exist in Java - Performance can be improve on the .NET runtime by refactoring I'm very glad to see George has picked up the ball to keep Lucene.Net going and applaud his commitment to keeping the project focused on it's stated goals: a line-by-line port of Java Lucene that releases in sync the main project. I'm also glad to see that a number of people have started contributing in meaningful ways to the Lucene.Net project, working through the action list George posted a few days ago. I would like to optimistically think that crisis is well on it's way to being averted. I think this is a good sign that Lucene.Net will remain a vital and active project as part of the ASF. With that said, I'd like to announce Lucere, a new Lucene-based .NET project. The goal of Lucere is to create a conceptual port of Lucene for .NET as contrasted with the current syntactic port approach taken by Lucene.Net. We will start by creating a ground-up re-write of the current feature set of Java Lucene 3.0.2 that is optimized for .NET. This is a non-trivial task and may cause our initial release cycle to be
Re: Porting Automation - Sharpen
As a user of Lucene, I would much rather have a .NET port than IKVM. The reasoning behind this is simple, I often need to extend Lucene, or modify it in some small ways, and it is much easier to do it if this is all a .NET project. On Wed, Nov 10, 2010 at 5:47 PM, Ryan Hoffman rhoff...@tntp.org wrote: I would say that performance is paramount, and I'm assuming that everyone else would agree. I think it's a great idea to try both IKVM and Sharpen and then make a few benchmarks that we compare both. Ryan Hoffman Software Architect The New Teacher Project www.tntp.org Evaluation systems are broken - so how do we fix them? Teacher Evaluation 2.0 - http://tntp.org/eval2.0 -Original Message- From: Hans Merkl [mailto:h...@hmerkl.com] Sent: Wednesday, November 10, 2010 8:37 AM To: lucene-net-...@lucene.apache.org Subject: Re: Porting Automation - Sharpen What I got from previous discussions was that IKVM works quite well, but some people don't like the idea because it produces its own wrappers around Java code. E.g. a collection won't be represented as .NET collection. Performance also seems to be close the .NET version (a bit slower). On Wed, Nov 10, 2010 at 01:43, Aaron Powell m...@aaron-powell.com wrote: Sorry I guess that's my naivety shinning through, I was under the impression that it was actually a way of producing .NET hooks into a Java API. If it's just a conversion tool I say we investigate it for sure. Aaron Powell Umbraco Ninja http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com On Wed, Nov 10, 2010 at 5:34 PM, Prescott Nasser geobmx...@hotmail.com wrote: If it spins up a VM just for conversion purposes, does performance matter much? It'll just be one of us converting it. If it has less pre / post work to convert correctly to a buildable solution, the extra overhead to convert is probably less painful. ~Prescott Nasser From: m...@aaron-powell.com Date: Wed, 10 Nov 2010 17:25:18 +1100 Subject: Re: Porting Automation - Sharpen To: lucene-net-...@lucene.apache.org What's the performance of IKVM? I'm skeptical about having to spin up a Java VM inside .NET and the kind of overhead that that would produce Aaron Powell Umbraco Ninja http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com On Wed, Nov 10, 2010 at 5:10 PM, Ryan Hoffman rhoff...@tntp.org wrote: Hey Guys, I'm loving all the recent activity on the dev list. I've been watching it for some time, and I was also deeply disturbed seeing no posts. This is my first message on the list :). I see that you are evaluating Sharpen. I was wondering if you've heard of IKVM, it's a Java VM that runs on top of .NET/Mono and it also includes a tool which can be used to convert java libraries/apps to .NET assemblies. Check it out at: http://www.ikvm.net/. If this works, it promises to be a very reliable way to convert the official java distribution to .NET. I will give this a shot soon and report back! Ryan Hoffman Software Architect The New Teacher Project www.tntp.org Evaluation systems are broken - so how do we fix them? Teacher Evaluation 2.0 - http://tntp.org/eval2.0 -Original Message- From: Aaron Powell [mailto:m...@aaron-powell.com] Sent: Thursday, November 04, 2010 10:25 PM To: lucene-net-...@lucene.apache.org Subject: Re: Porting Automation - Sharpen Nice work Alex with getting the ball rolling. I've decided to chuck the contents of that ZIP onto bitbucket (I hope you don't mind) since it'll be easier to track the testing against it than through an email. It's available here: http://hg.slace.biz/lucene-via-sharpen This is the raw package contents from Alex, I'll do some updates to it so that it's not tied to Alex's setup and works more generically (unless someone beats me to it) over the weekend http://hg.slace.biz/lucene-via-sharpenNote: This is NOT an attempt to move away from ASF, it's just a way for us to test out how well Sharpen performs as a tool for Java to .NET conversion, if it turns out to be a viable option this will be rolled back to ASF. This is just a playground :) Aaron Powell Umbraco Ninja http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com On Fri, Nov 5, 2010 at 12:52 PM, Alex Thompson pierogi...@hotmail.com wrote: I did an initial run of Lucene 3.0.2 through Sharpen. It stops when there is an error or finds something it
Prefix query performance
I run into an interesting perf issue just now. 100 runs of this query: Name:WILLY @ 224ms 100 runs of this query: Name:WIL* @ 790ms There are ~5000 documents in the index, two fields, Name is using StandardAnalyzer. Is there supposed to be that big a perf difference between the two?
Re: Range queries
Um, my understanding was that NULL or * was the way to specify an open ended range query, isn't that the case? On Wed, Jun 30, 2010 at 1:21 PM, digy digy digyd...@gmail.com wrote: just string comparison: '2' 'N' '*' '2' DIGY On Wed, Jun 30, 2010 at 1:04 PM, Ayende Rahien aye...@ayende.com wrote: I am seeing something strange with range queries: This works: Created:[20100730100201790 TO NULL] This returns no results: Created:[20100730100201790 TO *] This return no results: Created:[NULL TO 20100730100201790] This works: Created:[* TO 20100730100201790] Am I missing something?
