[kbkpbot]

Redis Client for V

[spytheman]

Excellent work.

[huly-for-github]

Connected to Huly®: V_0.6-23099

[einar-hjortdal]

This is a very naive implementation that requires complete rewrite in order to support cluster mode.
My concern is the quality of vlib libraries and the user experience they bring. I don't understand why you'd write this instead of contributing or forking what is already existing and being used.
I also don't understand why this would be merged despite #24074
@spytheman

[spytheman]

This is a very naive implementation

Simple implementations tend to be easier to support and maintain.
Simple and tested implementations even more so.

This happens to be both. I think it is a good addition to vlib, and I do think, that it will be easier to improve it, compared to some of the pre-existing external modules, which were not submitted as PRs here.

My concern is the quality of vlib libraries and the user experience they bring.

Mine too, as well as how easy they are to support and extend. I do think that the quality of the code here is high, and that your concerns (cluster mode) should be implemented on a higher level (a connection pool), and that even without it, the client here is usable (Redis is often used without any clustering, which is a relatively advanced feature, and these days a cheap single server can have the resources of several, just 5-10 years ago).

I hope that clarifies my position about why I merged it, and did not wait more, for a hypothetical thirdparty redis library to mature (which had 4-5 years at this point; I contributed to 2 of them, and I've implemented redis clients 3 times outside of V, in other languages) and to be submitted for inclusion in vlib.

[spytheman]

As for #24074, you write there:

Redis is relatively young

Redis started in 2009, which is 16 years ago. It is perhaps young relative to postgresql and mysql, but it had a lot of time to mature, and its protocol (the line based one) and basic usage is simple and not going to change. That is in fact part of why it was used so much - everyone could implement a client for it, and many people did, including me.

Creating a client for mysql/mariadb or postgresql/RDS/yugabyte/CockroachDB/etc is a lot more involved, and imho that is the reason why many choose to not do it from scratch, but instead to link to a library that implements it, and call its APIs instead.

[einar-hjortdal]

I understand your position now.
I disagree that this library is usable as it is now, it seems to suffer from the same issues that patrickpissurno/vredis was suffering from.
I wish I could rely on this library instead of having to use mine, because I do not want to maintain my own. I hope this matures fast.

[Delta456]

How about you contribute to the library to make it as usable as this one? This will speed up the development.

[einar-hjortdal]

How about you contribute to the library to make it as usable as this one? This will speed up the development.

I have other projects with higher priority. My redict library currently works well. I don't have time to work on yet another library, that's why I would like vlib's library to replace mine eventually.