test: introduce query integration tests#4745
Conversation
|
ACTION NEEDED The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification. For details on the error please inspect the "PR Title Check" action. |
dafa7da to
75ef95a
Compare
eabb397 to
a97a34e
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
| flags: unittests | ||
| fail_ci_if_error: false | ||
|
|
||
| integration_test: |
There was a problem hiding this comment.
does it make sense to call this query_integration_tests? Since we may add other kinds of integration test in the future to sophon.
There was a problem hiding this comment.
I'll add other integration tests for sure. But they will be in the same binary and I think run in the same CI job.
|
sorry, this is probably a dumb question, but why do these take much more time than our other tests? is it because of the greater volume of data here? |
Two motivations for saying this:
|
| ALL_FEATURES=`cargo metadata --format-version=1 --no-deps | jq -r '.packages[] | .features | keys | .[]' | grep -v -e protoc -e slow_tests | sort | uniq | paste -s -d "," -` | ||
| cargo test --locked --features ${ALL_FEATURES} | ||
| query-integration-tests: | ||
| runs-on: ubuntu-2404-8x-arm64 |
There was a problem hiding this comment.
| runs-on: ubuntu-2404-8x-arm64 | |
| runs-on: ubuntu-24.04-arm64-8x |
Implement fill_deleted_rows function to simulate deleted data by interleaving filler rows with id=-1. Add dynamic index parameter generation supporting scalar (BTree, Bitmap), vector (IvfFlat, IvfPq), and FTS (Inverted) indices. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Implement comprehensive test functions for dataset queries: - test_scan: Verifies scanning with ordering by id column - test_take: Tests taking specific rows by indices, validates against Arrow's take_record_batch - test_filter: Tests filtering with SQL predicates using DataFusion for comparison 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Fix generate_index_combinations to create cartesian product of all index options across columns, enabling tests with multiple indices - Add better error messages with expect() at key test setup points - Add test cases for duplicate indices in test_take - Document why _distance column isn't validated in ANN tests - Document that index parameters are for deterministic small test datasets 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Closes lance-format#5148 This adds a new integration test suite for queries. I decided to split up the test cases based on data type, as each one has different supported indices and query types. With this, it should be easy to add new test cases and have them automatically tested for many different dataset states. Each test is repeated for the combination of index types supported as well as table states. Right now, there are three dimensions of the table states: Fragmentation, Deletions, and File version. We can add more in the future. I think directly creating a particular state will be a more useful way to design tests than doing sequences of operations. ## Why run tests with optimizations Some of the tests are slow, and we plan to add a lot more of them. Here are timings for a clean build (no caching): | Level | build time | test time | |--------|--------|--------| | O2 | 10m 15s | 3.4s | | O1 | 7m 11s | 3.5s | | debug | 3m 15s | 18.79s | With caching and fast iteration in mind, I think O1 is a good balance. ## Feedback request The goal of this PR isn't to finish this test suite. I just want to focus on making sure we are happy with this test setup. We can easily add more test cases later. Let me know what you think of the framework. --------- Co-authored-by: Claude <noreply@anthropic.com>
Closes #5148
This adds a new integration test suite for queries. I decided to split up the test cases based on data type, as each one has different supported indices and query types. With this, it should be easy to add new test cases and have them automatically tested for many different dataset states.
Each test is repeated for the combination of index types supported as well as table states. Right now, there are three dimensions of the table states: Fragmentation, Deletions, and File version. We can add more in the future. I think directly creating a particular state will be a more useful way to design tests than doing sequences of operations.
Why run tests with optimizations
Some of the tests are slow, and we plan to add a lot more of them. Here are timings for a clean build (no caching):
With caching and fast iteration in mind, I think O1 is a good balance.
Feedback request
The goal of this PR isn't to finish this test suite. I just want to focus on making sure we are happy with this test setup. We can easily add more test cases later. Let me know what you think of the framework.