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

feat: RequestQueue v2 locking #59

Merged
merged 4 commits into from
Sep 13, 2023
Merged

feat: RequestQueue v2 locking #59

merged 4 commits into from
Sep 13, 2023

Conversation

vladfrangu
Copy link
Member

No description provided.

@vladfrangu vladfrangu requested a review from B4nan August 31, 2023 13:47
Copy link
Member

@B4nan B4nan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tests please

@barjin
Copy link
Collaborator

barjin commented Sep 11, 2023

Just checked the tests, and they seem fine to me :)

Some tiny nits:

  • I'm just (very slightly) confused about the prepared statements management - can we have a Record<statementName, Statement | null> for them?
  • And (on a very similar note), how about wrapping this._updateOrderNo.run({...}) in this.updateOrderNo({...}), which would basically be the _initUpdateOrderNo and this._updateOrderNo.run({...}) together? It might make the logic a bit clear (and we could ditch the preemptive calls to _initUpdateOrderNo in every method).

@B4nan
Copy link
Member

B4nan commented Sep 11, 2023

I'm just (very slightly) confused about the prepared statements management - can we have a Record<statementName, Statement | null> for them?

Same here, I was also a bit confused by that, but saw that it was done this way before... I'd argue we don't even need to go through the prepared statements for every single query, it makes sense only for those that will be repeated very often. Either way, this deserves some abstraction so we don't need to handle it again and again for every single query.

@vladfrangu
Copy link
Member Author

  • And (on a very similar note), how about wrapping this._updateOrderNo.run({...}) in this.updateOrderNo({...}), which would basically be the _initUpdateOrderNo and this._updateOrderNo.run({...}) together? It might make the logic a bit clear (and we could ditch the preemptive calls to _initUpdateOrderNo in every method).

Good point, will change

@vladfrangu vladfrangu merged commit 8dd40e8 into master Sep 13, 2023
5 checks passed
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

Successfully merging this pull request may close these issues.

3 participants