-
Notifications
You must be signed in to change notification settings - Fork 120
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
Make QueryResult::toString const #5013
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #5013 +/- ##
==========================================
+ Coverage 87.88% 87.91% +0.03%
==========================================
Files 1422 1427 +5
Lines 64377 64557 +180
Branches 7560 7576 +16
==========================================
+ Hits 56576 56755 +179
- Misses 7772 7773 +1
Partials 29 29 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
f7e918f
to
a1c7ffa
Compare
Benchmark ResultMaster commit hash:
|
9c33b9a
to
b27c401
Compare
b27c401
to
1193120
Compare
Benchmark ResultMaster commit hash:
|
Having toString mutate the query result means that in rust we can't use the Display trait (safely anyway). I think it's also somewhat unintuitive for it to mutate itself in this case.
I'd actually looked at this a while ago but had been attempting to separate the iterator from the QueryResult entirely (e.g. have a
QueryResult::iter
method that produces an iterator which has getNext/hasNext functions instead of having that be directly on the QueryResult, but that affected a lot of stuff so I never finished it.Instead, I've made it so that QueryResult::toString uses its own FlatTupleIterator/FlatTuple and avoids mutating the one from the QueryResult.
There will be a subtle difference in behaviour, as you can no longer start consuming the results and then use
toString
to print the remaining results, but hopefully that's not behaviour anyone was relying on.