Closed FujiokaD closed 7 months ago
👋 Thanks for the offer. But I think in general it's best if users check the redis server documentation. All these capabilities have evolved over time and if we start duplicating redis-server documentation here, it risks getting out of sync.
One thing that would be nice though would be to link to redis documentation on every methods.
it's best if users check the redis server documentation. All these capabilities have evolved over time and if we start duplicating redis-server documentation here, it risks getting out of sync.
I agree with you so I think only return keys matching the pattern
would be changed only return keys matching the pattern that acquired redis server acceptable regular expressions
or like you said only return keys matching the pattern To see the redis server documentation https://redis.io/docs/latest/commands/COMMAND/
Please advise me on nuances etc. as my native language is not English. It only need to modify the document and it will not affect the functionality, so I make a PR as soon as possible if you want.
as my native language is not English.
Mine isn't either 😅.
I think what would be best is to add a link to the server documentation for each command.
so e.g. def hscan
would have as last line of its documentation:
See the [Redis Server HSCAN documentation](https://redis.io/docs/latest/commands/hscan/) for further details
Or something close to that.
Documentation following methods have common description "the pattern", "the giving pattern", but acutually they have different acceptable regular expressions patterns.
Example:)
Redis::Commands::Keys#keys
allows [^e], [a-b] whileRedis::Commands::Pubsub#psubscribe
does not redis Command > KEYS: https://redis.io/docs/latest/commands/keys/ redis Commnand > psubscribe: https://redis.io/docs/latest/commands/psubscribe/I am willing to create a PR if you agree with the above idea