Skip to content

Transaction API features #6

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

Closed
whaatt opened this issue Sep 27, 2019 · 8 comments
Closed

Transaction API features #6

whaatt opened this issue Sep 27, 2019 · 8 comments

Comments

@whaatt
Copy link

whaatt commented Sep 27, 2019

Hi there (and sorry for creating all the issues)!

I noticed that the transaction API in typesaurus doesn't support querying within a transaction. In the types for Firestore, they allow transaction.get to take a query object (and acquire pessimistic locks on all the returned documents).

Adding query to the transaction API seems straightforward enough; is this something that could be added in the near-term?

Also, please let me know if I could help out with this task.

@whaatt
Copy link
Author

whaatt commented Sep 30, 2019

Also (and maybe this should be in a separate issue): Can the return type of transaction be parametrized by some T? Firebase recommends passing information out of transactions using the return value (which probably should be well-typed).

@whaatt whaatt changed the title Querying within a transaction Transaction API features Oct 1, 2019
@whaatt
Copy link
Author

whaatt commented Oct 1, 2019

One more idea I had: Firestore enforces that all reads precede all writes in a transaction. It seems like this could be enforced via types, by having transaction take two functions: one that performs reads (and only has access to t.get and t.query), and one that takes results from the read function and performs writes (with access to t.update and t.remove).

But maybe this is beyond the scope of the library?

@kossnocorp
Copy link
Owner

Hi there (and sorry for creating all the issues)!

No worries, thank you for taking the time and share your ideas. As I said in another issue I didn't receive notifications, so sorry for the long response. I really appreciate your interest in the library!

I noticed that the transaction API in typesaurus doesn't support querying within a transaction. In the types for Firestore, they allow transaction.get to take a query object (and acquire pessimistic locks on all the returned documents).

Wow, I didn't know that. Weird that it's not mentioned in the docs or simply missed it when worked on the function.

Do you know if it's supported by the web version as well?

Also, please let me know if I could help out with this task.

I'll be really happy, contributions are very welcome 🙏

@kossnocorp
Copy link
Owner

Also (and maybe this should be in a separate issue): Can the return type of transaction be parametrized by some T? Firebase recommends passing information out of transactions using the return value (which probably should be well-typed).

Good point, I've created a separate issue for that: #8

@kossnocorp
Copy link
Owner

kossnocorp commented Oct 25, 2019

One more idea I had: Firestore enforces that all reads precede all writes in a transaction. It seems like this could be enforced via types, by having transaction take two functions: one that performs reads (and only has access to t.get and t.query), and one that takes results from the read function and performs writes (with access to t.update and t.remove).

But maybe this is beyond the scope of the library?

That's an interesting idea and might help new developers. When I just started with Firestore I remember how I was confused by the transaction limitations.

How do you the API? Maybe something like this?

transaction({
  read: t => { /* ... */ },
  write: (readResults, t) => { /* ... */ } 
})

I've created an issue for that: #9

@whaatt
Copy link
Author

whaatt commented Oct 30, 2019

Yep, something like that would be great!

@niklasravnsborg
Copy link

@whaatt @kossnocorp Working with the API now, it would be very cool if every Typesaurus function returns an interface or some kind of typed object. For example I'm using the batch() function and need to pass it to multiple consumer functions as an argument. It would be very helpful for me if I could define this input argument with some kind of type.

For example:

import { batch, Batch } from 'typesaurus'

const foo = (batch: Batch) => {
  batch.set(...)
  batch.commit(...)
}

const myBatch: Batch = batch()
foo(myBatch)

Greetings :)

@kossnocorp
Copy link
Owner

Closing the issue as I addressed all the feedback, thank you a lot @whaatt!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants