-
Notifications
You must be signed in to change notification settings - Fork 516
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 ordering options to askar scan and fetch_all methods #3173
base: main
Are you sure you want to change the base?
Conversation
6445449
to
58ddd54
Compare
Marking ready for review just to see integration test results |
a53412b
to
df0b339
Compare
@ff137 Is this working for you to test changes to the aries-askar library? I've been trying to do the same thing, with a fork of aries-askar, committing the I think i might have something wrong with some meta data or my python env. |
@jamshale Hmm, I got the same error in the integration run: https://github.com/hyperledger/aries-cloudagent-python/actions/runs/10451102652/job/28936801431 At first I couldn't run the PR tests locally, but resolved when I added just But, we could get our end-to-end tests passing here: didx-xyz/aries-cloudapi-python#989, using this ACA-Py branch, so it seems it builds fine in different contexts |
For interest, the following commit shows the end-to-end tests that asserts unique records are returned across pages, when scanning with limit/offset: didx-xyz/aries-cloudapi-python@00c3f0f Those tests had to be commented out because lack of ordering made results inconsistent, and it seems the askar changes + this branch resolves that 😃 Will wait for askar release including those changes, and perhaps adding tests here, before marking this PR ready |
ac6097a
to
97709d2
Compare
4df9492
to
90cd53c
Compare
@jamshale I managed to get integration tests passing - using an aries_askar TestPyPI package 👀 90cd53c Last couple commits here show how I uploaded to TestPyPI: ff137/aries-askar#1 |
Great, thanks. I'm going to give this a try. |
90cd53c
to
7bd4f39
Compare
4f79524
to
c08e416
Compare
Quality Gate failedFailed conditions |
2a7bc47
to
a2cecc4
Compare
…ll methods Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
…ing by created_at) Signed-off-by: ff137 <[email protected]>
…oes additional sorting Signed-off-by: ff137 <[email protected]>
Signed-off-by: ff137 <[email protected]>
a2cecc4
to
f1626b2
Compare
Quality Gate failedFailed conditions |
Any status update on this PR so we can raise it in the ACA-Pug meeting tomorrow -- 2024.11.16 @ 8:00 Pacific / 17:00 Central Europe? |
Essentially just needs an official askar release (currently using my test-pypi package / fork of askar). And some minor rebasing. |
Signed-off-by: ff137 <[email protected]>
Quality Gate passedIssues Measures |
✨ Adds
order_by
anddescending
options to paginated scan or fetch_all methods❗ This PR is waiting for next official Askar release
🚧 At present, uses TestPyPI package to test ordering functionality introduced in Askar: openwallet-foundation/askar#291
To-do: test coverage, and point to next aries-askar release that includes this change.
Notes: currently it only appears to ever make sense to order by the "id" column, since record field values are encrypted.
So, it does feel a bit weird allowing users to select an "order_by" column when there's only one valid choice. But, I still believe it's better than nothing. We at least add the functionality for control over ordering, and it can be disabled (for whatever reason) by requesting None. Ordering by id is effectively the same as ordering by time created (AFAICT), so the newest records can be received at the top by selecting descending=True. Perhaps this can be made default behavior.
At present (before this Askar PR is merged), there is no guaranteed ordering when fetching records, for the scan (paginated queries) or fetch all methods. This means there's no solid guarantee that all records will be retrieved while scanning (with increasing offsets), and ordering of records may be inconsistent across many fetch_all calls. So, resolving that is the motive for this contribution.
Will close #3001