Hi
Gamma doesn’t seem to have everything ready for SQlite?
The library doesn’t seem to be parsing correctly, maybe it’s a version or something.
"Couldnt find file’
For example, it is not possible to follow the instructions and examples:
I also tried several different database libraries and nothing seems to work well. So far the most promising is SQLNado. Do you have any idea what’s better to use?
please share a patch demonstrating the problem.
Not totally related, but stumbled upon this thing a while ago :
It claims it can automagically create a REST API on top of any database. Have not actually tested it, but that could allow to approach databases in an agnostic way, without having to develop a node set for all types.
But while we’re on the subject, here’s an example on sqlnado, where things don’t work too well either
sqlnado.zip (6.7 KB)
@sebescudie I’m testing different options.
I understand that there are a number of ways to make the databases external. I’m just trying to use the bloat-free approach - quickly create a database with nodes, easily work with it with nodes. What I’ve come across in the last few years are telegram bot users. It’s dozens of times easier to make a bot with users in Python than it is in Gamma now.
We had a look at System.Data.SqLite and turns out it is a rather tricky nuget to use. Let’s consider it not supported.
But SqlNado actually works fine out of the box. Haven’t played with it extensively, but this example creates a db and then dumps it to the console:
sqlnado.vl (20.0 KB)
@joreg, thanks!
Interesting trick! I hadn’t figured it out and thought it wouldn’t work at all.
We can then conclude that sqlnado seems to be the most suitable option for uncomplicated projects.
What about how to designate key fields, primary keys?
looks like there is some issues because of it
upd: the issue may be deeper than it seems
and the last time I wrote, I ran into similar problems.
Why do you need SQL in first place you can do json, I think under 700 000 elements you should be good to go
@antokhio To be honest, you may be right
Perhaps the biggest problem with JSON is that it does not work well with simultaneous reading and writing. What to do if several events change the contents of the database?
t’s also an interesting way to push the limits of what’s possible with VVVV. This might be of interest to potential programmers.
Well since all the data stored in the ram I think you should be good, at list I did that for a project, just dumped bunch of tables in json (around 100k row), read it in the class, then did few methods to get data async, not 100% percent sure about writing, but I think if you use async or sync, (no parallel) it should work quite descent. However I would not recommend to use native deserialiser/serialiser and use some sort of small plug in c# that does deserialisation and querying (this would avoid bloat (technical fields that gamma does)).
Also if you looking for performant solution for key value pairs you should look to redis and not SQL
That’s the problem. I don’t want to store data in memory, it would be cool to store all data, load, save, backup from disk. While in principle your approach works in many cases.
Redis is an interesting option. But it is difficult to deploy on Windows. Potentially interesting option when Gamma becomes multiplatform
Haven’t used it myself but maybe worth checking out:
Well the data stored it ram means the deserialised data, e.g objects, you store and read data from json. With redis data is also not persistent, meaning it’s gone after reboot
