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.

Sign up for GitHub

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

Jump to bottom

Remove set data type #1010

Merged
merged 9 commits into from Aug 10, 2020
Merged

Remove set data type #1010

merged 9 commits into from Aug 10, 2020

Conversation

mavam
Copy link
Member

@mavam mavam commented Aug 7, 2020

No description provided.

@mavam mavam added the refactoring Restructuring of existing code label Aug 7, 2020
@mavam mavam marked this pull request as ready for review August 7, 2020 11:25
dominiklohmann
dominiklohmann requested changes Aug 10, 2020
View reviewed changes
Copy link
Member

@dominiklohmann dominiklohmann left a comment

Choose a reason for hiding this comment

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

I looked at this thoroughly, have run the tests locally as well. Just some minor remarks, mostly LGTM.

integration/queries/multi_addr.txt
@@ -1 +1 @@
:addr in { 192.168.1.1, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.1, 192.168.1.255, 192.168.1.1, 192.168.1.1, 192.168.1.1, 224.0.0.251, ff02::fb, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.1, 192.168.1.255, 224.0.0.251}
:addr in [ 192.168.1.1, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.1, 192.168.1.255, 192.168.1.1, 192.168.1.1, 192.168.1.1, 224.0.0.251, ff02::fb, 192.168.1.255, 192.168.1.255, 192.168.1.255, 192.168.1.1, 192.168.1.255, 224.0.0.251]
Copy link
Member

Choose a reason for hiding this comment

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

Does it make sense for this query to still have duplicated fields?

Copy link
Member Author

Choose a reason for hiding this comment

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

The old set never enforced uniqueness, so now that this is a vector, it's the exact same behavior.

Copy link
Member Author

Choose a reason for hiding this comment

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

But now that you mention it, we probably should have a story to perform a "uniquing" pass when using in with vector operands.

CHANGELOG.md Outdated Show resolved Hide resolved
libvast/test/parse_data.cpp Show resolved Hide resolved
libvast_test/src/table_slices.cpp Outdated Show resolved Hide resolved
dominiklohmann
dominiklohmann approved these changes Aug 10, 2020
View reviewed changes
Copy link
Member

@dominiklohmann dominiklohmann left a comment

Choose a reason for hiding this comment

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

Thanks for the changes. Can you take care of filing a ticket for the optimization for in operations with lists that you suggested?

@mavam mavam merged commit 66220c1 into master Aug 10, 2020
@mavam mavam deleted the story/ch18399 branch August 10, 2020 14:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dominiklohmann dominiklohmann dominiklohmann approved these changes

Assignees
No one assigned
Labels
refactoring Restructuring of existing code
Projects
None yet
Milestone
No milestone
2 participants
@mavam @dominiklohmann