Skip to content

streaming interface for get #2304

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
RichardWright opened this issue Oct 25, 2022 · 7 comments
Open

streaming interface for get #2304

RichardWright opened this issue Oct 25, 2022 · 7 comments
Labels

Comments

@RichardWright
Copy link

Hi

Would it be possible to add support for a nodejs streaming interface? (https://nodejs.org/api/stream.html)

Thanks

@leibale
Copy link
Contributor

leibale commented Oct 25, 2022

This is impossible with RESP2, and will be possible only when Redis implements RESP3 "Streamed String"

@leibale leibale added feature and removed Bug labels Oct 26, 2022
@karankraina
Copy link

@leibale While it is not possible currently with RESP2, can we add a helper function in the library that uses range command to get chunked values from redis and return a nodejs readable stream?

I tried to implement this in ioredis, but that is no longer actively maintained. I can open a similar PR here, if it looks okay. Thoughts?

Reference PR - redis/ioredis#1922

@leibale
Copy link
Contributor

leibale commented Oct 14, 2024

@karankraina That's an interesting idea! :) One concern I have is whether we can detect if a key changes "mid-stream" and handle it appropriately. For instance, if we have a key with a length of 1024 and we're reading in chunks of 64, what happens if someone runs a SET command after we've already read two chunks? Will we be able to detect the change and abort the stream?

(Also, just to note: streamed strings aren't currently implemented in Redis [the server], so even after RESP3 support is available on the client side, we'll still need to wait for the server to implement streamed strings before we can fully support a readable stream.)

@karankraina
Copy link

@leibale I initially thought about that too. But I'm afraid I dont have any clue if we can do that currently. I think, for now, we can maybe have a warning message on getStream and let end users handle this, no ?

@karankraina
Copy link

Hi @leibale ! Should we go ahead with this ?

@leibale
Copy link
Contributor

leibale commented Oct 20, 2024

@karankraina if we can't detect/handle it:

  1. how do we expect the "user" to handle it?
  2. the warning will always be there (as we can't detect it)

@karankraina
Copy link

@leibale By handling I mean, users should own this part about their redis key. As there is no way for the lib to know if a key value has changed in redis, users must only use this method if they are sure that the data wont be updated. Like for example, a static cache.

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

3 participants