search

apache / lucene

Apache Lucene open-source search software
https://lucene.apache.org/
Apache License 2.0
2.63k stars 1.02k forks source link

Integrate lat/lon BKD and spatial3d [LUCENE-6699] #7757

Closed asfimport closed 9 years ago

asfimport commented 9 years ago

I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :)

Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points.

I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering.

But, second: what do we index into the BKD tree? Can we "just" index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing "surface lat/lon" bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)?

Migrated from LUCENE-6699 by Michael McCandless (@mikemccand), 1 vote, resolved Sep 02 2015 Attachments: Geo3DPacking.java, LUCENE-6699.patch (versions: 26) Linked issues:

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

OK, actually, at indexing time you'll hit an exc already if the x/y/z is ever out of bounds (encodeValue checks this) ... but, are there any known PlanetModels with a larger max than the 1.002 I randomly picked!

I committed the "remove 3D query bbox opto".

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

are there any known PlanetModels with a larger max than the 1.002 I randomly picked!

Well, you can construct your own planet model object. Presumably if you were modeling something pretty oblate, like Saturn, 1.002 would not do. I provided the min/max methods precisely so you could determine this for real. But at the moment we can go ahead and get things working before crossing that bridge, if you like.

asfimport commented 9 years ago

Nick Knize (@nknize) (migrated from JIRA)

Introducing a stray dependency outside of spatial3d seems like it would make maintenance more of a nightmare rather than less.

I don't recall module dependency for Geo3D being an issue when it was part of the spatial package, now we have spatial code in 3 separate modules and suddenly you oppose module dependency? It makes no sense and this disarray of spatial functionality only introduces more confusion, disorganization, and a wider gap for getting more spatial contributors involved. Nevertheless, I assume (hope) it resolves itself in time, otherwise lucene spatial capabilities will continue to fragment.

I don't recall you complaining over the last seven months about geo3d's architecture and organization...

Rather combative. Don't confuse my suggestions for keeping things light, approachable, and organized, as holding any enmity towards geo3d.

I guess it's all part of the bigger question is whether geo3d should remain separable from Lucene.

I still prefer it be a part of core/util so that (once again) the 90% geo use case can be accomplished with no dependencies other than core. Having it in a 3d specific package seems no better than simply moving it to Apache SIS (where all EPSG ellipsoids, OGC compliance, etc. are already provided). But that's not my call.

For me, Geo3d at the moment needs to remain as a working whole without dependencies on the rest of Lucene

This messaging seems to change based on the agenda. Not that it matters except for keeping in mind whats best for the lucene project as a whole.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Rather combative. Don't confuse my suggestions for keeping things light, approachable, and organized, as holding any enmity towards geo3d.

I am not trying to be combative; I'm interested in the same things you are, although I seem to look at the world a bit differently perhaps. My major concern is that since January there's been quite a bit of back-and-forth with David Smiley and others about various aspects of geo3d organization, structure, abstractions, etc., and it seems like we'd be undoing quite a bit of what was agreed on then to meet your concerns now?

I still prefer it be a part of core/util so that (once again) the 90% geo use case can be accomplished with no dependencies other than core. Having it in a 3d specific package seems no better than simply moving it to Apache SIS (where all EPSG ellipsoids, OGC compliance, etc. are already provided). But that's not my call.

Unfortunately, I have constraints, in addition to Lucene. I cannot at the moment contribute to Apache SIS, without going through a laborious and time consuming company process. So if/when geo3d leaves Lucene, I won't immediately be able to leave with it.

Also, as we've discussed before at some length, geo3d was developed and optimized specifically for the search problem. While that seems like a minor thing at first glance, it's actually quite a big deal. My impression was that this was pretty far from the Apache SIS core mission.

This messaging seems to change based on the agenda. Not that it matters except for keeping in mind whats best for the lucene project as a whole.

I've got two masters here. First, it's essential that my company continues to be able to use geo3d, even before it is released via lucene. Remember that development is taking place all the time on both sides. Right now, geo3d is reasonably separable, and we've deliberately built the dependency structure to maintain that. That was one of the reasons behind having a separate module.

If/when geo3d is actually pulled into core (which I still don't know will definitely happen or not), then it's a different ballgame, and integration with other core code will likely take place. But that hasn't happened yet and may never happen.

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

I'll address the "rename" nocommits shortly...

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695494 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695494

LUCENE-6699: fix some nocommits

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695510 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695510

LUCENE-6699: add basic test for the point field / query

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

I committed a basic test, but it fails in a fun way:

Time: 0.202
There was 1 failure:
1) testBasic(org.apache.lucene.bkdtree3d.TestGeo3DPointField)
java.lang.IllegalArgumentException: X values in wrong order or identical
    at __randomizedtesting.SeedInfo.seed([71BA4E421B49E771:DA405357C495615F]:0)
    at org.apache.lucene.geo3d.XYZSolid.<init>(XYZSolid.java:94)
    at org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1$1.compare(PointInGeo3DShapeQuery.java:124)
    at org.apache.lucene.bkdtree3d.BKD3DTreeReader.intersect(BKD3DTreeReader.java:190)
    at org.apache.lucene.bkdtree3d.BKD3DTreeReader.intersect(BKD3DTreeReader.java:129)
    at org.apache.lucene.bkdtree3d.BKD3DTreeReader.intersect(BKD3DTreeReader.java:113)
    at org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1.scorer(PointInGeo3DShapeQuery.java:99)
    at org.apache.lucene.search.Weight.bulkScorer(Weight.java:135)
    at org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
    at org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:618)
    at org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:92)
    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:425)
    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:544)
    at org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:402)
    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:413)
    at org.apache.lucene.bkdtree3d.TestGeo3DPointField.testBasic(TestGeo3DPointField.java:58)

I think the X values are in fact identical ... I indexed a single point into the BKD tree, and so minX == maxX and the recursion uses these global min/max when recursing ... I think I might just remove the global min/max and instead recurse from the full int space. This was a change I had "tried" vs the 2D BKD tree and I think I don't like it :)

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695513 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695513

LUCENE-6699: don't use the global min/max

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

I think I don't like it

OK I removed it and now testBasic passes!

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

On the module dependencies, I think it's fine if we have some small code dup for now across modules. We will sort this out over time: maybe sandbox depends on spatial3d, or vice versa, or we "graduate" the postings-based and 2D BKD implementations from sandbox into spatial3d (and rename it), or move them into core/util, or ... something. I think we shouldn't fret about it at this point: things are moving quickly and it's a little too early to figure out where things will eventually land.

I've got two masters here.

This is fine.

We all (necessarily: capitalism) have our own sometimes conflicting motives for improving Lucene (and other open-source projects), but it works out that when you sum up all those motives across all players what emerges is something that benefits many, many people.

moving it to Apache SIS

I think the Apache SIS project should feel free to poach geo3d at any time, but ...

Selfishly (for Lucene) I think we should also keep it here as we iterate on the "unique" requirements we have for efficient searching. E.g. here in this issue we already see that we need new APIs in geo3d for the BKD integration, maybe future issues require more such iterating.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Well, as we discussed a while back, I'm going to need to implement some "degenerate" solids in any case, if this all works, and a factory method that picks among them. That's a better fix methinks than changing stuff around. I'll get going on that tonight.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Ok – let me synch up and see what new feature should have what priority...

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695616 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695616

LUCENE-6699: fix more names

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695619 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695619

LUCENE-6699: fix more nocommits

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

This patch adds the basic architecture for handling degenerate cases of XYZSolids. Still need to implement the specific cases though.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Updated patch, including degenerate (but untested) classes for single-dimension degeneracy. Still four additional degeneracy classes to implement.

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I committed the last patch.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Hmm, either there was an svn hiccup, or you got the wrong patch. ;-)

Actually, it appears that I uploaded the same patch twice, so it's my fault. But in any case, attaching a new one based on the current branch status.

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695700 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695700

LUCENE-6699: another iteration on degenerate solids

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I committed the last patch

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Patch to complete the degenerate solid classes and construction logic. @mikemccand: I will be adding some unit tests for this code, later today or tomorrow.

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695950 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695950

LUCENE-6699: more degenerate solids

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1695951 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1695951

LUCENE-6699: more degenerate solids

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I committed these to the branch... I'll work on fixing the test case to test the indexing and searching, not just the lower level direct unit tests for the BKD3DTree.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Add basic tests for degenerate shapes, as well as a fix for degenerate single point. @mikemccand, hopefully you can remove all constraints now about generating identical min/max values in your random tests.

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696089 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696089

LUCENE-6699: add tests, fix bugs

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696090 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696090

LUCENE-6699: more degenerate solids

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I committed your last patch to the branch. I think I'll leave the "global min/max" opto out, but, handling degenerate solids is still necessary because an adversary could have a bunch of identical points as a subset of non-identical points, which can cause degenerate cells even if the global min/max are not degenerate.

I also got testRandom working, it uncovered some fun bugs, but seems to be passing now!

I think we're getting close...

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

I've been considering the question of how to get x,y,z bounds for the purposes of optimization. It's a bit more complex than I originally thought; maybe I'll have an idea by tomorrow. The complexity revolves around the fact that x,y,z bounds are always explicit, but lat/lon bounds have concepts like "no longitude bound" and "no top latitude bound".

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

I think I worked it out; I should have a usable patch sometime later this morning. With that, I think the geo3d additions are complete, so yeah, we're getting closer. ;-)

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Hmm, ran into another snag. I think I had better think this through over the next day or so.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Revamp how we do bounds, so we can compute (x,y,z) bounds cheaply too.

This patch has a couple of known issues, and needs tests too, both of which I'll be addressing shortly.

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I'll commit shortly.

I ran the same "225 bboxes around London on the 61M OpenStreetMap lat/lon points" perf tests with the current branch, plus the 3 other existing options:

All these benchmarks are in luceneutil.

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696275 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696275

LUCENE-6699: first cut to support x,y,z bounds

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

@DaddyWri I committed the patch but svn got a bit furious:

mike@haswell:/l/3dbkd$ svn patch patch.x
U         lucene/spatial/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShape.java
C         lucene/spatial/src/test/org/apache/lucene/spatial/spatial4j/Geo3dShapeRectRelationTestCase.java
>         rejected hunk `@@` -58,7 +58,8 `@@`
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/Bounds.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoBaseShape.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoCircle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoCompositeMembershipShape.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoConvexPolygon.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateHorizontalLine.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateLatitudeZone.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateLongitudeSlice.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegeneratePoint.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoDegenerateVerticalLine.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoLatitudeZone.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoLongitudeSlice.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoNorthLatitudeZone.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoNorthRectangle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoPath.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoRectangle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoShape.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoSouthLatitudeZone.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoSouthRectangle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideDegenerateHorizontalLine.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideLongitudeSlice.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideNorthRectangle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideRectangle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWideSouthRectangle.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/GeoWorld.java
A         lucene/spatial3d/src/java/org/apache/lucene/geo3d/LatLonBounds.java
U         lucene/spatial3d/src/java/org/apache/lucene/geo3d/Plane.java
A         lucene/spatial3d/src/java/org/apache/lucene/geo3d/XYZBounds.java
>         hunk `@@` -138,7 +138,7 `@@` already applied
>         hunk `@@` -145,6 +145,7 `@@` already applied
>         hunk `@@` -154,6 +155,7 `@@` already applied
>         hunk `@@` -160,12 +162,12 `@@` already applied
>         hunk `@@` -81,7 +81,7 `@@` already applied
>         hunk `@@` -88,6 +88,7 `@@` already applied
>         hunk `@@` -96,18 +97,13 `@@` already applied
U         lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoBBoxTest.java
U         lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoCircleTest.java
U         lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoConvexPolygonTest.java
U         lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoModelTest.java
U         lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoPathTest.java
U         lucene/spatial3d/src/test/org/apache/lucene/geo3d/GeoPolygonTest.java
>         hunk `@@` -27,16 +27,15 `@@` already applied
>         hunk `@@` -67,5 +66,160 `@@` already applied
Summary of conflicts:
  Text conflicts: 1

I resolved the one conflict by hand, but can you svn up and confirm things look OK? Tests did pass after applying the patch...

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696276 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696276

LUCENE-6699: round up when dividing by 2 to find size of BKD tree

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

It all looks OK. I don't know why svn was unhappy. Maybe I should rebuild my workarea...

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

FWIW, @mikemccand, I convinced myself that the one case I was worried about should, in fact, not be an issue. So you should be able to start using XYZBounds to obtain bounds information for shapes.

Specifically, you want to do this:

XYZBounds bounds = new XYZBounds();
myshape.getBounds(bounds);
double minX = bounds.getMinimumX();
...

I will work on the tests shortly, but that's basically all there should be to it. Please let me know if you find any weird behavior.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

patch to remove unused code

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696299 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696299

LUCENE-6699: remove unused code

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I'll try using the bounds in the BKD tree ... and I committed your last patch!

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696305 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696305

LUCENE-6699: use bbox, but test fails

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

OK I fixed the query to use the new XYZBounds API, but I hit NPE:

   [junit4] Suite: org.apache.lucene.bkdtree3d.TestGeo3DPointField
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPointField -Dtests.method=testBasic -Dtests.seed=1600287909381DEB -Dtests.locale=el_CY -Dtests.timezone=America/Mexico_City -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.22s J0 | TestGeo3DPointField.testBasic <<<
   [junit4]    > Throwable #1: java.lang.NullPointerException
   [junit4]    >    at __randomizedtesting.SeedInfo.seed([1600287909381DEB:BDFA356CD6E49BC5]:0)
   [junit4]    >    at org.apache.lucene.bkdtree3d.PointInGeo3DShapeQuery$1.scorer(PointInGeo3DShapeQuery.java:102)
   [junit4]    >    at org.apache.lucene.search.Weight.bulkScorer(Weight.java:135)
   [junit4]    >    at org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
   [junit4]    >    at org.apache.lucene.search.AssertingWeight.bulkScorer(AssertingWeight.java:69)
   [junit4]    >    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:618)
   [junit4]    >    at org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:92)
   [junit4]    >    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:425)
   [junit4]    >    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:544)
   [junit4]    >    at org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:402)
   [junit4]    >    at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:413)
   [junit4]    >    at org.apache.lucene.bkdtree3d.TestGeo3DPointField.testBasic(TestGeo3DPointField.java:90)
   [junit4]    >    at java.lang.Thread.run(Thread.java:745)

Is it expected that sometimes the bounds would be null? If so, I could just swap in Integer.MIN/MAX_VALUE for that dimension... (seems like in this failure it's only the z dimension that's null).

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

They are not expected to be null. I have a fix for the problem (happened to hit it myself just moments ago).

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

Some tests and some fixes

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

@mikemccand: Here's an updated patch that has a fix for the problem I discovered.

asfimport commented 9 years ago

Karl Wright (@DaddyWri) (migrated from JIRA)

And, yet another patch which cleans up stuff

asfimport commented 9 years ago

ASF subversion and git services (migrated from JIRA)

Commit 1696334 from @mikemccand in branch 'dev/branches/lucene6699' https://svn.apache.org/r1696334

LUCENE-6699: cleanups

asfimport commented 9 years ago

Michael McCandless (@mikemccand) (migrated from JIRA)

Thanks @DaddyWri, I committed your last patch, but I'm still seeing (different) test failures ...