Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DWithin geo function #3238

Merged
merged 5 commits into from Feb 11, 2016
Merged

Add DWithin geo function #3238

merged 5 commits into from Feb 11, 2016

Conversation

hhakimi53
Copy link

DWithin function finds whether two given geo objects are within specified distance of each other. Supported arguments:

  • First two input arguments are geo objects which can a point and a polygon, a point and a point. Both arguments can't be polygons as distance within two polygons is not supported
  • Third arguments is non-negative distance argument on which two geo objects are evaluated whether they are within that distance range or not.

+ "from borders, places where (distance(borders.region, places.loc) <= 50000) and borders.pk = 1 "
+ "order by distance, places.pk;";
vt2 = client.callProcedure("@AdHoc", sql).getResults()[0];
assertEquals(vt2, vt1);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a sensible equals operator defined for VoltTable? I didn't know this.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More importantly, is equals sufficient for the testing you're doing here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent of the logic is to make sure the result from both of the queries match to verify the DWithin is working as expected as well cross check our other geo functions :). Voltable::equals() is deprecated and is intended for testing use only as per the comments. Based on the logic it seems it will assert if contents of two table are not same. I will look into if can use some other call instead. The downside to equals is it will not report which table row is different. Please let me know if you had other thoughts on it. Thnxs

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is no better alternative in RegressionSuite somewhere, then what you have here seems okay---but if equals is deprecated it suggests that it may go away someday?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is assertTablesAreEqual() in RegressionSuite to check if the contents of two tables are equal. So can use that one instead.

@wolffcm
Copy link

wolffcm commented Feb 3, 2016

The only thing I see missing as far as testing is passing a NULL as the distance argument. Perhaps I missed it. Besides that, this looks good to me. Definitely demo-able at the end of iteration meeting as well.

@hhakimi53
Copy link
Author

test case with NULL argument for distance is missing. I will add the test case for that. Thnxs for the feedback.

@wolffcm
Copy link

wolffcm commented Feb 5, 2016

That's all my comments on your latest commits.

@wolffcm
Copy link

wolffcm commented Feb 11, 2016

Looks good. Thanks Huzefa. If this is ready to merge, you can demo it tomorrow?

@hhakimi53
Copy link
Author

Thanks Chris for reviewing it again. Sure, I can try to demo it tomorrow. There are no merge conflicts with master so we should be able to push the changes to the master.

hhakimi53 pushed a commit that referenced this pull request Feb 11, 2016
Add DWithin geo function
@hhakimi53 hhakimi53 merged commit dad9108 into master Feb 11, 2016
@hhakimi53 hhakimi53 deleted the ENG-9306 branch February 12, 2016 21:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants