-
Notifications
You must be signed in to change notification settings - Fork 762
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
feat: KeyValueStore.recordExists()
#2339
Conversation
Thanks for the approval, but also please see the description if you have the time 😄 What is our modus operandi when updating storage, and what changes need to be made and where? The more I think about it, the less I remember how we do this. |
Sounds fair to me, not sure what @B4nan thinks about it 👀
We still are supposed to maintain it, yes (even tho I also don't like it 😢). If you've got more burning stuff on your plate I can handle that once we merge this in! |
Cheers, that's what I thought 👍🏽 but we should probably have it in the |
Yes and yes, we want to require the latest client in all of the places that require the new API, and this needs to work with the sqlite storage too. |
Testing for record existence with
getValue()
puts an unnecessary load on the Apify Platform / the storage backend - the client has to load the value just to throw it away in the next step.recordExists()
tests for the existence of a KVS key-value pair without actually retrieving the value itself.side note: we should probably bump the
apify-client
dependency inapify-sdk
, release a new version(?) and have Crawlee depend on this (and greater) versions ofapify-sdk
, right?Also, it's been some time since I did something with the storages, what's the procedure there? Are we still maintaining the
apify-storage-local
package - if so, we should probably add this method there as well