Database usage for plugin data

Hi,

I've used serialize.save_simple so far to save plugin state. After taking an introductory course in database systems though at university, I've been thinking about switching over to using sql lite.

What would be the downsides of switching to this? For example, how fast would the queries be compared to say hand-coding traversal of lua tables to achieve the similar result (which is what I used to do before I learnt SQL)? SQL lite also doesn't fully support alter table, which is something I may need to do for e.g a new version of the plugin adding a new option, how much of a problem is this?

You can work around not being able to alter table with a little dance of copy table, drop table, create table, select->insert, drop table. The only real issue I've ever had with sqlite is its lack of either NATURAL OUTER or FULL OUTER join, I forget which one, but it was definitely one of them, and the only real workarounds require knowing the table columns ahead of time which I couldn't because of the configurable nature of the project. I ended up implementing them brutefully in Python, which the rest of the project was written in.

I don't see what this has to do with serialize, though.

It's a discussion about how to save state, basically.

---

I used the SQLite3 stuff for the mapper (in some cases) and found it quite fast enough. For multiple updates, put them inside a transaction. For reading, it is fast.

What you can do (and I think I did in the mapper) is cache things from the database into a Lua table - for reading, not updating.

Hm, doesn't that not allow you to perform sql queries if you read the database entries into a table, and so have to code that yourself?

Does what not allow you to what?

Converting it into a lua table, doing that won't allow you to run sql queries against the table?

No, you can't run SQL queries against a Lua table, but what did you have in mind? Data in a table can usually be looked up by key, or by searching (eg. string.match) of things that you want in the data.