Skip to content

Replace promise wrapper & callbacks for native async/await? #1138

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

Open
jimmywarting opened this issue Apr 6, 2020 · 2 comments
Open

Replace promise wrapper & callbacks for native async/await? #1138

jimmywarting opened this issue Apr 6, 2020 · 2 comments
Labels

Comments

@jimmywarting
Copy link

it's not an issue with the current promise wrapper...
But to me it seems like it just add overhead/complexity to the architecture to mix both callbacks and promises - now i haven't looked much at the source code yet to have any say at it.

maybe it's just too large/complex to make any changes or maybe someone is using an extra callback parameters. Maybe it's due to some more lower level api that makes reading streams not doable or you are supporting older node versions? or someone is using a own custom promise lib like bluebird. or you simply just use a dependency that only works with callbacks.

And changing it could be a breaking change

there could be many reason for closing this issue since it's not really an issue. But maybe this could be a long term goal?

if it's reading packages from stream and adding listeners to when you receive data
maybe a replacement could be to use the new asyncIterator that's available in newer node versions?

I could imagen a lower level api to work something like this:

const connection = connect({ config })
const iterator = connection[Symbol.asyncIterator]()

async function query (query, params) {
  ...
  connection.write( build(query, params) )
  nextPackage = await iterator.next()
  const result = parsePackage( nextPackage )
  ...
  return result
}
@sidorares
Copy link
Owner

it's a mix of all the reasons, at the moment I don't see a compelling reason to rewrite low level core with more modern primitives. At the same time happy to continue improving public api ergonomics

Mysql packets are quite difficult to parse without context, you need to know which type of packets you want to parse before you start. Because of that internal logic is a bit more complex than "serialize a packet, send, read incoming packets, deserealize", we need to have some sort of state machine to use correct parser for a packet

There is a bit of discussion of using async iterators to fetch rows here - #822 (comment)

@sidorares
Copy link
Owner

for example, this is state diagram for query command:

image

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

No branches or pull requests

2 participants