Mysql Save and Load List.

ID:2272039
 
Jul 20 2017, 12:18 pm
(See the best response by Ter13.)
Code:
I used list2params to save and it worked
i used dd_list2text to save and it worked
but i can't get it to load the list and put the contents back.


When it comes to loading i've tried
src.contents=params2list(row_data["contents"])
src.contents=dd_text2List(row_data["contents"])
src.contents=dd_text2List(row_data["contents"],"&")


Problem description:
How can i make it so it saves and load lists like contents and skills.



Jul 20 2017, 2:41 pm
Best response
Relational databases don't save variable length data in columns. You will want to create a fixed length field or create a separate table for the items and refer back to the uniqueid of the container.
Jul 20 2017, 10:38 pm
So you're implying it's 100% impossible to save lists in general? One way or the other, a list would be involved somewhere, weather is be via item IDs or some other method. You can't change an items type variable either so... Could you try to explain with a bit more detail please?
Jul 20 2017, 11:15 pm (Edited on Jul 20 2017, 11:20 pm)
Backing a game with a database isn't a simple topic that can be glossed over quickly.

You can't save variable-length lists easily. You need to determine an upper bound for each column in a database, and you need to be able to deal with situations where the column might exceed the limits of the column.

So it's better to just not serialize lists into columns, but use entire tables to construct inventories.

Basically, instead of having inventory as a property of the player table, you would want to build the inventory by creating a separate table for items:

table itemstacks {
    uniqueid instance
    int playerid
    int itemid
    int stack
}


To build the player's inventory, you would query from itemstacks where playerid = the unique id of the player you are loading from the player table.

itemid would link to a lookup table that you would clone copies of item instances from with their own distinct properties.

So an actual item table might look like:

table items {
    uniqueid itemid
    int maxStack
    int equipEffect (cross-table to a list of effects)
    int equipSlot
    int enchantid (cross-table to a list of enchants)
    int useEffect (cross-table to a list of effects)
    int value
    int creator (cross-table to a player)
    string[128] description
    string[32] name
}


Or it could just be a 1:1 association of ids and modified types jammed into a savefile and loaded into memory at startup. You'd have to keep the whole thing in memory, but would only need one in memory no matter how many instances of that object exist. Think of the actual items the player has in their inventory as shell objects that just refer to the singleton objects from the dictionary.

The trick is to keep all of the information about the class of item itself as separate as possible from the inventory and stacks of items themselves.