[go: nahoru, domu]

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.

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

[FR] expose Preconditions in the set call for the admin API #1697

Open
jakebiesinger-storyhealth opened this issue Mar 10, 2022 · 2 comments
Assignees
Labels
api: firestore Issues related to the googleapis/nodejs-firestore API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@jakebiesinger-storyhealth

(the Firestore Node Admin API folks sent me over here from firebase/firebase-admin-node#1597)

Describe the problem

The Admin API exposes an update method which includes Preconditions. This allows us to specify that a document update call should fail if the DB document was modified after the precondition.updateTime. This is a nice way to make sure that REST API callers don't overwrite documents that were simultaneously modified.

Unfortunately, the set method does not expose a way to specify a similar Precondition, which means we can only specify Preconditions when updating an existing document, and not when we want to replace it wholesale.

Relevant Code:

// Setup
const ref = db.doc('/some/path');
const v1 = {foo: 'bar'};
await ref.set(v1);
const t1 = await ref.get().then((d) => d.updateTime);

// I can use preconditions with update
await ref.update({bim: 'baz'}, {lastUpdateTime: t1}); // This will succeed
await ref.update({bim: 'boing'}, {lastUpdateTime: t1}); // This will then fail due to the precondition

// But the result is a merged document. I want to *replace* the document as this is a REST API
await ref.get().then((d) => d.data());  // --> {foo: 'bar', bim: 'baz'} but I want just {bim: 'baz'}

// So we try to use `set` instead 
await ref.set({bim: 'baz'}); // but there is no way to specify the precondition above

Workarounds:

  • I can manually read the existing document and throw an error myself if the precondition isn't met, but that makes for awkward transactions (which expect to do all reads before any writes).
  • I could enumerate top-level fields and spread across them with a FieldValue.delete() overridden by the new document (something like ref.update({...{field1: delete(), field2: delete()}, ...theNewDoc}), but this is also really awkward. While I know my top-level types, enumerating them is hard in typescript (where types are erased at runtime).

(ported over from firebase/firebase-js-sdk#6058 and firebase/firebase-admin-node#1597)

@jakebiesinger-storyhealth jakebiesinger-storyhealth added priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Mar 10, 2022
@product-auto-label product-auto-label bot added the api: firestore Issues related to the googleapis/nodejs-firestore API. label Mar 10, 2022
@dconeybe dconeybe self-assigned this Mar 14, 2022
@dconeybe
Copy link
Contributor

@jakebiesinger-storyhealth Thank you for making this feature request. Your use case sounds reasonable so I'll look into it. I hope to have a reasonable response within 7 days from now.

@dconeybe
Copy link
Contributor

@jakebiesinger-storyhealth We discussed this as a team today and we're going to try to find a solution for this. The current idea is to add a lastUpdateTime member to the SetOptions type, and I'll prototype that change. Note that we have other priorities so it could take some time for this to get done, and I cannot promise any particular timeline.

Another workaround for you would be to use a transaction (i.e. Firestore.runTransaction()) which will lock the document and ensure that any writes are performed on the document that was read.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: firestore Issues related to the googleapis/nodejs-firestore API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

2 participants