Serialized values in the database

[tryagain]

Why are they there? Are they used for anything? It's pretty troubling.


Thanks,


Tim

[geshi]

What's your other solution ?

[tobz]

They are there to store dynamic data.

They are ugly as shit, but it is what it is! Would be nice to convert them to JSON instead of semicolon-delimited.

[Argo]

Why are they there? Are they used for anything? It's pretty troubling.


Thanks,


Tim

we are using them for example to give a npc many diffrent models, to give mobs a certain lvlrange, to have a model with many diffrent sizes etc... and yes they are good for something. Since i am the one who wanted it to be this way, please don`t change it. I will defend these serialized values since it makes the world of daoc a bit mor randomized and wipes away the borin g feeling of having always this forseeable mobs actions and what do i know more.... So look but please don`t touch the system

@ tobz, they can also be ranged from xxx-yyy not only serialized

kind regards
Argo

[geshi]

You can do the same job, but another way... I think that's what tryagain is getting at.. for example at the moment my characters spec in the db is stored as "Nurture|44;Regrowth|32;Blades|3;Blunt|1;Music|37"

There could be dolcharacterxspec table.. with columns CharID, Spec and Amount.. easier to read I guess but it would be a lot of work to convert existing data for EVERYTHING to do with serialisation in DOL I guess

[Argo]

You can do the same job, but another way... I think that's what tryagain is getting at.. for example at the moment my characters spec in the db is stored as "Nurture|44;Regrowth|32;Blades|3;Blunt|1;Music|37"

There could be dolcharacterxspec table.. with columns CharID, Spec and Amount.. easier to read I guess but it would be a lot of work to convert existing data for EVERYTHING to do with serialisation in DOL I guess

I agree on this one Geshi, it is quite difficult to read sometimes. Might be a real good idea to put that specs in another table like the one you suggested.

kind regards
Argo

[Graveen]

generally the 'hard to exploit' reason is to read 'need to but read by a tool'.

There are tons of things that are stored in either binary or any 'performance-oriented' format that are not really human readable. I'm rather pro coding a simple but efficient tool than twisting the stored datas to reach the non-goal "human readable".

Of course, when they match (or if they are close enough to have both benefits of performance and readability) then, let's go !!!!

[tryagain]

I decided to work up the patch to switch this from serialized fields to separate tables.

[Hiatus]

That might not be the best choice for DoL atm, that would mean major DB reconstruction (well atleast I think so) and also I'm pretty sure you would bump into some other major issues with mobs. Also this would mean major code alteration. Unless it's just for personal use..

[geshi]

You should start with RA's first, they will be quite simple to do and it's a needed change :p

[tryagain]

I've actually decided to do anything serialized in the DOLCharacters table. I've got most of the work done already for several of them. It will have some implications for the DOLCharactersBackup table that I need to investigate in addition to a necessary upgrade script. How have upgrades been handled in the past the require db structure changes? I was thinking a table with a single entry for the database version with database upgrade scripts run by the server at startup might be one possibility.

[Graveen]

We used to handle a database conversion tool (you can perhaps find it in the deep 2k versions, iirc i removed it), but i suggest to simply provide SQL. Thumbs up !

[tryagain]

It's not as simple as providing SQL in this case (or it may be to SQL gurus but not me). Since you have to convert the serialized data to table data it requires parsing and manipulation outside of SQL statements. Obviously the changes to the structure of the tables will be SQL but I was talking about providing a path from a currently populated DB to the new structure.

[Tolakram]

My primary concern with this will be performance under load and synchronizing in a threaded environment. We already have some issues with cached character data linked to accounts (via the DOLDB relation functionality) using old data. How will this perform under load and is this a 'it's theoretically better' change or a change that's really needed.

Just remember, at this stage in DOL's life, this will provide just another reason for people to break away from the core. I've already done it on D2 and, frankly, will probably not go back. It's just too much work for a part time server operator to manage.

That's all I'm going to say about this. It's a good idea, I hate serialized data as well, but will require vigilance.

[Tolakram]

That's all I'm going to say about this. It's a good idea, I hate serialized data as well, but will require vigilance.

That's interesting, since dataquest is all serialized. I dislike some serialized data.