3 ms·

I tried to spawn a new thread for each request and it was embarrassedly slow, maybe I was doing something wrong from my side, but I believe I will settle for a

by siscia 10y ago

I tried to spawn a new thread for each request and it was embarrassedly slow, maybe I was doing something wrong from my side, but I believe I will settle for a pool. About the reply the only thing that I see manageable is to include the name of the columns as first row, I was considering the idea but I am not completely sold yet. I was thinking to bind a particular statement to a key in order to provide the possibility to have standard queries between different clients REDISQL.CREATE_STATEMENT insert_user "INSERT INTO users VALUES($1, $2, $3)" > OK REDISQL.EXEC_STATEMENT insert_user name, password, email > OK or with multiple insert in the same transaction REDISQL.CREATE_TRANSACTION > "REDISQL.TRANSACTION_12345" REDISQL.EXEC_STATEMENT "REDISQL.TRANSACTION_12345" insert_user name1 password1 email1 > OK REDISQL.EXEC_STATEMENT "REDISQL.TRANSACTION_12345" insert_user name2 password2 email2 > OK REDISQL.EXEC_STATEMENT "REDISQL.TRANSACTION_12345" insert_user name3 password3 email3 > OK REDISQL.COMMIT_TRANSACTION "REDISQL.TRANSACTION_12345" > 3 # as the number of statement executed

arielm 10y ago
Just to throw my two cents into the mix. The idea of being able to _query_ a single key in a SQL-like fashion is interesting, but I can't think of a production implementation that would be useful enough. Instead, I'd look at using redis in front of something like MySQL so some operations go to redis and other right to the server. Having to write SQL statements as redis EXECs isn't elegant IMO.
- siscia 10y ago
  > Just to throw my two cents into the mix. You have no idea how much those 2 cents are appreciated, really, I mean it. > The idea of being able to _query_ a single key in a SQL-like fashion is interesting Not sure I understood what you mean here. Would you mind to provide some kind of example or to explain it further? > Instead, I'd look at using redis in front of something like MySQL so some operations go to redis and other right to the server. Extremely interesting, how you discriminate though ? If it is going to be a "regular" cache you don't need a module, redis can already do it by itself. What use case you were think of? > Having to write SQL statements as redis EXECs isn't elegant IMO. I do completely agree, the API is going to get more structured for sure.
deleted 10y ago
[deleted]

by siscia 10y ago

arielm 10y ago

Just to throw my two cents into the mix. The idea of being able to _query_ a single key in a SQL-like fashion is interesting, but I can't think of a production implementation that would be useful enough. Instead, I'd look at using redis in front of something like MySQL so some operations go to redis and other right to the server. Having to write SQL statements as redis EXECs isn't elegant IMO.

siscia 10y ago
> Just to throw my two cents into the mix. You have no idea how much those 2 cents are appreciated, really, I mean it. > The idea of being able to _query_ a single key in a SQL-like fashion is interesting Not sure I understood what you mean here. Would you mind to provide some kind of example or to explain it further? > Instead, I'd look at using redis in front of something like MySQL so some operations go to redis and other right to the server. Extremely interesting, how you discriminate though ? If it is going to be a "regular" cache you don't need a module, redis can already do it by itself. What use case you were think of? > Having to write SQL statements as redis EXECs isn't elegant IMO. I do completely agree, the API is going to get more structured for sure.

deleted 10y ago

[deleted]