AutoIT and Redis

[RamDemon]

Hi,

Did anyone tried to  use Redis  with AutoIT as store DB ?

 Redis <-- more about it

Mladen

[mLipok]

This is interesting but ...

Is't SQLite have similar features ?

 

[RamDemon]

SQLLite - Local data, Redis - Server side data.

I am still  learning  about redis features.

 

[mLipok]

45 minutes ago, RamDemon said:

Redis - Server side data.

????
 

I do not understand what you mean.

Did I misunderstod something here:

https://redis.io/

Quote

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.

 

Edited September 25, 2018 by mLipok
typo

[RamDemon]

Well  Redis  listens on port 6379 TCP, and it can act as remote server for  clients.

https://redis.io/clients

As far I know SQLLite is local based SQL  , or  am I wrong?

 

 

[mLipok]

27 minutes ago, RamDemon said:

https://redis.io/clients

Clients >> Modules >> UDF >> Include >> .... this is not a feature in Redis technology .... this is only a "framework" which allow you to use Redis in an easy way.

 

Edited September 25, 2018 by mLipok

[mLipok]

33 minutes ago, RamDemon said:

Well  Redis  listens on port 6379 TCP, and it can act as remote server for  clients.

This not mean that Redis works in Client/Server mode (with concurent connection).
But I can be wrong as I do not read entire Redis documentation.

33 minutes ago, RamDemon said:

As far I know SQLLite is local based SQL  , or  am I wrong?

SQLite db file can be store on remote shared folder, and in this way you can work with the same database on different client/station but not at the same time.

btw.
I think we need to ask @jchd about Redis feature.

Edited September 25, 2018 by mLipok

[jchd]

Never had experience with Redis either. I've very little time to look deep at it.

Just looked what it became and I still have hard time seeing how SQLite and Redis would naturally work together. The former is a SQL RDBMS while the latter is a proprietary datastore. The underlying models of both products don't trivially compare. Yet such mixes have been tried in countless combinations.

There are myriads of ways to mix SQL and NoSQL products, sometimes with perfectly valid reasons, other times just to follow current hype.
The only real question is: "why do you think you have to?"

Once you have loads of strong pro arguments and little or no against, then just go. Else seriously question your premises.
Use Google translate if required: http://sametmax.com/nosql-arretons-de-dire-nimporte-quoi/

[TheDcoder]

9 minutes ago, jchd said:

The former is a SQL RDBMS while the latter is a proprietary datastore.

Isn't Redis open-source? How can it be a proprietary datastore if it is free software

[Earthshine]

i think he means it's not sql rdbms it's their own dog food https://redis.io/

 

"Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster"

Edited September 25, 2018 by Earthshine

[jchd]

So call it "proprietary to its own open source code". I meant it isn't anywhere close to an established model or standard. That's the same with all (AFAIK) NoSQL products. Not that all are bad or useless, but everything fashionable isn't necessarily the panacea to all situations in the universe. That's the meaning of the article I quoted.

Notice that your data has a structure by itself, even very simple, and the relationships between data entities do denote a semantical structure reflecting problem specificities. Putting everything in a modelless bag may not reveal the most clever move just because you have to enforce relationship integrity thru application code rather than by means of strict built-in rules that SQL allows you to edict.

[Earthshine]

i'm also not seeing any advantages, or how they would work together either. I can't see the vision I guess.

[TheDcoder]

8 hours ago, jchd said:

So call it "proprietary to its own open source code". I meant it isn't anywhere close to an established model or standard. That's the same with all (AFAIK) NoSQL products.

That doesn't really make sense to me, it doesn't have to be an established model or "standard" to be non-proprietary. The code is free for anyone to use and modify etc.

8 hours ago, jchd said:

Not that all are bad or useless, but everything fashionable isn't necessarily the panacea to all situations in the universe. That's the meaning of the article I quoted.

I don't see how this is related to Redis being a "proprietary" datastore, it is as you have said, one of the many solutions to certain situations, just like how other SQL-like databases are

[jchd]

What I wanted to point out is that at some point in time, a number of no-SQL database-like codebases appeared and rapidly attracted a huge number of developpers. That's the "O dear, that's new and everyone's talking about it so I need to join" effect.

After some time it became clear that all these datastore solutions aren't the panacea they were often claimed to be. Of course many/all of them have a good use in specific contexts. What attracted attention is that all these libraries don't enforce strict rules like SQL does, the new land of the free if you want. Again this is an illusion in many situations since both your data and relationships underneath do exist and have to be enforced somewhere.

I didn't mean proprietary as "copyrighted property of some big corp", but "ad-hoc code".

[TheDcoder]

5 hours ago, jchd said:

I didn't mean proprietary as "copyrighted property of some big corp", but "ad-hoc code".

I see, I didn't get that meaning from your posts before

5 hours ago, jchd said:

What I wanted to point out is that at some point in time, a number of no-SQL database-like codebases appeared and rapidly attracted a huge number of developpers. That's the "O dear, that's new and everyone's talking about it so I need to join" effect.

I agree, I am no fan of the hype bandwagon either. Any good developer worth their salt should know what to use according to their specific situation, in this case OP has not given any clear indication of how they are going to use it, but maybe the want a simple key-value datastore like Redis...

5 hours ago, jchd said:

What attracted attention is that all these libraries don't enforce strict rules like SQL does, the new land of the free if you want. Again this is an illusion in many situations since both your data and relationships underneath do exist and have to be enforced somewhere.

I have personally never used a DB or datastore before, so I cannot go into the specifics, but it does look like SQL-like databases are somewhat overkill for small general purpose key-value databases, many projects of that sort never use the other fine tuned features of SQL (at-least that is how it looks like). Feel free to correct me if I am wrong

[jchd]

4 hours ago, TheDcoder said:

I have personally never used a DB or datastore before, so I cannot go into the specifics, but it does look like SQL-like databases are somewhat overkill for small general purpose key-value databases, many projects of that sort never use the other fine tuned features of SQL (at-least that is how it looks like).

Correct but I can see other arguments as well.

I'm a daily reader of the SQLite mailing list, an amazing source of inspiration. A question regularly pops up there as "How can I associate SQLite and <some key-value store>?" and once the dust settles it pretty often turns out that SQLite alone is more suitable to the case exposed than some kind of "marriage of carp and rabbit" (a French saying). At times a counter-intuitive more sophisticated setup is the right choice due to uncommon requirements.

SQLite is special in the SQL world. It's a zero-install, fast, small footprint, flexible, embedded RDBMS having no dependancy and being compiled and used on the largest range of hardware/software platforms ever. It was created as a [TCL] application general purpose datastore and has evolved to what it is today.

A good share of developpers never having used SQL think of it as a caterpillar: a mainframe-style monster from the COBOL era, or something close to that picture. I've been there before but quickly changed my mind.

There are countless occasions where you start thinking about and coding something "simple" that should be "good enough", just to realize after some time that you have to recode into a much more complex way. A common example is log files. You start with a flat text file, then store stuff with timestamp/the_rest then have to recode with timestamp/station/the_rest, then again as timestamp/station/status/the_rest, further as timestamp/station/status/error_class/the_rest, ... each time having to satisfy more and more detailled queries or statistics or whatelse, like safe concurrent accesses.
Starting at once with something powerful is often a long-term guarantee.

[TheDcoder]

@jchd Understandable, I am in somewhat middle of the both arguments, I start simple and then if things start getting complex (like the log file example) I will rewrite the portion of it using something better suited

There are also people like @TheSaint who would prefer to go all simple (key-value) even though it become somewhat complex in the end... All about choice and personal preference it seems, ultimately programmers (who know what they are doing) will choose the solution which is more maintainable to them

P.S Looks like we have derailed this topic, not sure if it is a good idea to split the posts.