Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Lucene.Net 3.0.3
    • Fix Version/s: Lucene.Net 3.0.3
    • Component/s: None
    • Labels:
      None

      Description

      We need to port MemoryIndex from contrib, if we want to be able to port a few other contrib libraries.

        Issue Links

          Activity

          Hide
          Troy Howard added a comment -

          I started in on porting this, however this one has a few challenges to replicate exact behaviour.

          It uses Java wildcard generics in a Comparator<T> implementation, of which there is no .NET equivalent. I could probably replicate behaviour using Reflection but I'm not sure how that will impact performance vs it's Java equivalent. May need to redesign a little to accomodate .NET type system.

          Show
          Troy Howard added a comment - I started in on porting this, however this one has a few challenges to replicate exact behaviour. It uses Java wildcard generics in a Comparator<T> implementation, of which there is no .NET equivalent. I could probably replicate behaviour using Reflection but I'm not sure how that will impact performance vs it's Java equivalent. May need to redesign a little to accomodate .NET type system.
          Hide
          Christopher Currens added a comment -

          If you're talking about the termComparator, that wasn't made generic until 3.1. The comparator in 3.0.3 can't be ported the way it is anyway because of Java's type system, but I just want to make sure you're porting 3.0.3 to keep everything in line with the rest of the .NET versions. You'll find that the 3.x version in java uses a few other additions to the main lucene library that aren't yet available in 3.0.3.

          This problem should be easily solved without reflection. The comparator used basically requires that it be a KeyValuePair<TKey, TValue>, or more specifically, a KeyValuePair<string, TValue>. There are actually only 2 different types that uses that termComparator: KeyValuePair<string, ArrayIntList>[] and KeyValuePair<string,Info>[]. An exception to that is the private static sort(Dictionary<K,V>) method, but that can be solved with a static method, a type constraint (which is already implied in the java version) and some type inference (as a nicety). I had ported most of this at one point (somewhere on my home computer), and if memory serves me correctly, I think this is how I solved this problem.

          You can use this if you want:

          class KvpComparer
          {
              public static int Comparer<TKey, TValue>(KeyValuePair<TKey, TValue> x, KeyValuePair<TKey, TValue> y)
                  where TKey : IComparable<TKey>
              {
                  if (x.Equals(y)) return 0;
                  return x.Key.CompareTo(y.Key);
              }
          }
          
          sealed class KvpComparer<T> : KvpComparer, IComparer<KeyValuePair<string, T>>
          {
              public int Compare(KeyValuePair<string, T> x, KeyValuePair<string, T> y)
              {
                  return Comparer(x, y);
              }
          }
          

          You can create the two instances you need for the <string,Info> and <string,ArrayIntList> types. For the Map.Entry<K,V>[] sort(HashMap<K,V> map method, constrain K to IComparable<K>, and then you can use it like Array.Sort(entries, KvpComparer.Compare), which is nice because it's one less object you need to create (or more) for each type passed into sort. Alternatively, since the sort method is private, and only uses those two types, you can just change the signature and pass in one of the comparers instead, removing the base class from the equation.

          Show
          Christopher Currens added a comment - If you're talking about the termComparator, that wasn't made generic until 3.1. The comparator in 3.0.3 can't be ported the way it is anyway because of Java's type system, but I just want to make sure you're porting 3.0.3 to keep everything in line with the rest of the .NET versions. You'll find that the 3.x version in java uses a few other additions to the main lucene library that aren't yet available in 3.0.3. This problem should be easily solved without reflection. The comparator used basically requires that it be a KeyValuePair<TKey, TValue> , or more specifically, a KeyValuePair<string, TValue> . There are actually only 2 different types that uses that termComparator: KeyValuePair<string, ArrayIntList>[] and KeyValuePair<string,Info>[] . An exception to that is the private static sort(Dictionary<K,V>) method, but that can be solved with a static method, a type constraint (which is already implied in the java version) and some type inference (as a nicety). I had ported most of this at one point (somewhere on my home computer), and if memory serves me correctly, I think this is how I solved this problem. You can use this if you want: class KvpComparer { public static int Comparer<TKey, TValue>(KeyValuePair<TKey, TValue> x, KeyValuePair<TKey, TValue> y) where TKey : IComparable<TKey> { if (x.Equals(y)) return 0; return x.Key.CompareTo(y.Key); } } sealed class KvpComparer<T> : KvpComparer, IComparer<KeyValuePair<string, T>> { public int Compare(KeyValuePair<string, T> x, KeyValuePair<string, T> y) { return Comparer(x, y); } } You can create the two instances you need for the <string,Info> and <string,ArrayIntList> types. For the Map.Entry<K,V>[] sort(HashMap<K,V> map method, constrain K to IComparable<K> , and then you can use it like Array.Sort(entries, KvpComparer.Compare) , which is nice because it's one less object you need to create (or more) for each type passed into sort. Alternatively, since the sort method is private, and only uses those two types, you can just change the signature and pass in one of the comparers instead, removing the base class from the equation.
          Hide
          Christopher Currens added a comment -

          I hope you don't mind, but I had so much free time this week, I went ahead and ported this. It's been a few days since I mentioned I might be doing this on the mailing list in the email titled "Lucene.NET 3.0.3 Release Date", so I hope you had at least seen it before this happened (no one has yet to respond to the email).

          Tests and Library have been ported. Everything looks pretty good, There were a few weird things related to term comparisons, so there are some small minor differences between the Java, but it's fairly obvious with the constraints listed.

          Show
          Christopher Currens added a comment - I hope you don't mind, but I had so much free time this week, I went ahead and ported this. It's been a few days since I mentioned I might be doing this on the mailing list in the email titled "Lucene.NET 3.0.3 Release Date", so I hope you had at least seen it before this happened (no one has yet to respond to the email). Tests and Library have been ported. Everything looks pretty good, There were a few weird things related to term comparisons, so there are some small minor differences between the Java, but it's fairly obvious with the constraints listed.

            People

            • Assignee:
              Unassigned
              Reporter:
              Christopher Currens
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development