[Solved] Persistent Storage of Tables

Post Reply
Nius
New member
Posts: 3
Joined: Mon Feb 04, 2019 06:43
GitHub: Nius
IRC: Nius
In-game: Nius

[Solved] Persistent Storage of Tables

by Nius » Post

Greetings, all.

I'm working on developing some mods that will require the ability to persistently store tables between instances. I'm having some difficulty determining the best way to accomplish this, however, and I was wondering if some advice might be available.

I see that the StorageRef provides a means of working with tables, but in my searching for documentation and examples I encountered this reply by a developer indicating that this was not the way to go.

I see the article about database backends but as I understand it this is for the engine to use, not for mods.

I'm wondering if there is any natively supported by Minetest means of quickly reading and writing persistent tables, even if it means only reading and writing whole tables at a time, without writing my own means of disguising tables as the primitive types supported by the StorageRef.

Thank you all for your time.

sofar
Developer
Posts: 2132
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: Persistent Storage of Tables

by sofar » Post

my comment didn't mean "don't use this storage method at all".

The storageref API (mod_storage) is meant to handle individual key/value settings. Each of these can themselves be an (encapsulated) table. You can do this by e.g. using minetest.serialize() and minetest.deserialize() the tables to values that can be stored and later retrieved from these keys.

This allows you to put many tables into mod_storage.

If you have a unique case where you have a single table that is flat (not nested, only has simple key-value pairs that are integers or strings, essentially) and you only ever read them whole, and store them whole, then the to_table and from_table methods are reasonable to use.

The reason that I don't recommend this method is because you only ever get ONE mod_storage objectref in your mod. If you need to store *something else* later, you can't if you organized your data wrong. Therefore, it's slightly better to just stuff your data in a key-value sense, then to use to/from_table. It gives you more flexibility later on.

Using mod_storage is recommended for *any* data, including your tables. I use this myself in most of the mods, especially in the typical case where you read something at startup, and write when things change or on shutdown.

Nius
New member
Posts: 3
Joined: Mon Feb 04, 2019 06:43
GitHub: Nius
IRC: Nius
In-game: Nius

Re: Persistent Storage of Tables

by Nius » Post

Thank you!

Serializing will solve my problem perfectly, and I'm grateful that Minetest provides methods for doing this. Thanks for illuminating that for me.

Just to tie up my understanding, I read this to mean that to/from_table() are for cases where the entire storage payload exists in a single table and from_table() could be expected to overwrite the entire file. This is why you'd rather we use the other methods, because they're meant to play nice with each other. Do I understand this right?

In any case, you've solved my problem. Thank you very much for your time!

sofar
Developer
Posts: 2132
Joined: Fri Jan 16, 2015 07:31
GitHub: sofar
IRC: sofar
In-game: sofar

Re: Persistent Storage of Tables

by sofar » Post

Nius wrote: Just to tie up my understanding, I read this to mean that to/from_table() are for cases where the entire storage payload exists in a single table and from_table() could be expected to overwrite the entire file. This is why you'd rather we use the other methods, because they're meant to play nice with each other. Do I understand this right?
Exactly that.

Nius
New member
Posts: 3
Joined: Mon Feb 04, 2019 06:43
GitHub: Nius
IRC: Nius
In-game: Nius

Re: [Solved] Persistent Storage of Tables

by Nius » Post

Fantastic. Thank you again for your time.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests