Unable to use natural sorting with a property assigned a Converter or Format about lucene.net.linq HOT 9 CLOSED

Incidentally, ordinal and range queries work perfectly when using a Format or Converter on a DateTime field.

Btw, I tried just using the date field as a string and parse/formatting it on the client side. That fixes the sorting problem, but Lucene.Net.Linq gets confused when you try to do an ordinal (or presumably range) query on a string, so that turned out to not actually be a solution either.

from lucene.net.linq.

I have used DateTime or DateTimeOffset and stored them as numeric fields and haven't noticed any major performance issues. However, I'll try to reproduce this issue to see if I can find a bottleneck.

from lucene.net.linq.

Please make note that I'm not saving the dates as a NumericField, but just as regular fields using the DateTools static methods.

from lucene.net.linq.

I wrote a test case to see if I could find a performance problem, and I found that native sorting and sorting with IComparable take about the same amount of time (476ms vs 499ms to sort 25,000 fields).

In any case, the test code shows a somewhat round-about method of preventing IComparable sort from being triggered. It seems like a good idea for the client to be able to suppress this behavior and use simple alphanumeric sorting, so I'll keep this open as a request to do that.

from lucene.net.linq.

Actually modifying the test a little to not retrieve all documents, but only the first, and rerunning the queries to take advantage of a warm field cache shows native executes in 2ms vs 22ms for IComparable.

That is a big difference. I've used a caching converter in one of my projects to improve performance, but still it makes sense to offer a simple way to use native sorting.

from lucene.net.linq.

Sorry I haven't left a comment about this for a while. But yes, that's EXACTLY the issue: using the custom comparators requires Lucene to fetch the documents because it can't use the contents of the index. Incidentally, I haven't tried this, but I assume that the custom comparators will only work on fields that are stored.

from lucene.net.linq.

I believe the custom sort implementation does not work much differently than native fields and should work on fields that are indexed but not stored, but I haven't tested that either. While it's true each field for each document in the index must be loaded, this isn't much different from how the native implementations work. I think the performance penalty is in actually converting each field to its complex type which is where caching can mitigate the problem. This seems to be confirmed by the tests I ran today: 20ms of overhead compared to native after the field cache is warm.

from lucene.net.linq.

3dc9585 adds NativeSort as an option on attribute/fluent mappings. Disabled by default.

from lucene.net.linq.

Released: https://nuget.org/packages/Lucene.Net.Linq/3.2.54

from lucene.net.linq.