Encon

Upgrade Files for SQL Synchronization

Recommended Posts

Just thought I'd point out that because there are no upgrade files for SQL synchronization, this commit causes some pretty exciting bugs if you're using SQL dbs and don't manually make the changes.

Git Hash: 84df170

In particular, resist potions suddenly have the lovely effect of inflicting Stone Curse on the user for a very long time, which probably isn't quite what the user wants.

I have no idea if this a unique case or if there's been other times that it happened, but it would probably be a good idea to start adding SQL upgrade files when the item (and mob?) db is updated, perhaps in their own subfolder. Or at the very least include upgrade files in cases like this where changes to the source can introduce major bugs without the corresponding database changes.

Share this post


Link to post
Share on other sites

The item and mob sql files can be imported into your database at any time and will keep your tables up to date. The SQL Synchronisation commits keep the SQL files up to date with the txt databases.

Share this post


Link to post
Share on other sites

Sorry, I forgot to mention that part. Many servers are going to have customized item/mob databases, even if it's just a few minor changes, so replacing the entire database isn't going to be an option since it'll overwrite all previous changes.

Basically the SQL Synchronization commits only work for completely new servers, or servers that use an entirely vanilla item/mob database (which probably isn't the majority case). It would be good to have an actual upgrade option for established servers that need the updates as well, especially when constants are being changed like that.

Share this post


Link to post
Share on other sites

The SQL files should be ran in order to update your database. If you have any customs or amendments to official items, they should be in *_db2. That is the purpose of those tables. Anything in there is read after the base table, so if you have a Red Potion in item_db with normal item script, you can have a Red Potion (501) in item_db2 and whatever stats this item has will supercede the item stats from item_db. We set this up to prevent anything from being overwritten. 

Share this post


Link to post
Share on other sites

That still seems a bit less than ideal in my opinion, since a minor tweak will overwrite the entire line, but alrighty. I suppose my suggestion still stands - I do think upgrade files or possibly some other setup would be more convenient - but I understand it's not really a priority thing to look into.

Share this post


Link to post
Share on other sites

If the line is in db2 then your custom item takes priority regardless of what the item has as stats in the normal db.

We already have the functionality you're looking for, were not going to change the process in order to arrive at the same outcome.

Custom stuff has always gone into db2, this process has worked fine for thousands of servers since the code was created over a decade ago.

Share this post


Link to post
Share on other sites

If you're going to fail to read and comprehend my post, you may want to cut down on the arrogance. I've been entirely polite this whole time, and all I'm doing is making a suggestion.

As I said above, if you make a minor tweak to an item using item_db2, for example changing the weight and nothing else, it replaces the entire line. Using my initial post as an example, if I changed only the weight of the resist potions, then the current upgrade functionality would not work, because even though the item use script has been left completely unchanged, the full line is being replaced by this minor tweak in weight. The functionality I'm asking for is not currently present.

I'm aware that it's possible to manually apply these changes regardless, I was simply pointing out that the upgrade process could potentially use some improvements for convenience. Just because something has "worked for thousands of servers," doesn't mean it's perfect and can't be made better. In any case, I already said I know there's other priorities since this is just a minor convenience thing, no need to be an ass about something you chose not to read.

Share this post


Link to post
Share on other sites

I did read and I understood your post. I apologise if I've come across as arrogant - I was simply trying to re-iterate my point that we provide a method of allowing custom items to exist without updates interfering with them. It's your job to look over commits that you apply to your local repo to check for conflicts.

The mechanics you're looking for aren't feasible in the current setup, but perhaps @Secrets might have a way in the C++ version to create a method of overwriting single item/mob values?

Share this post


Link to post
Share on other sites

I understand we should be looking over the changes as well, I just thought it could possibly be improved to make that task a little less tedious in cases where there may be a large number of minor item tweaks.

Setting it up to overwrite single values would work as well, for sure. One potential way of doing it could be to skip null values when reading item_db2 so you could, for example, add a line with only the item ID and weight. In cases where someone wanted to "reset" a column they'd simply set it to 0 or a blank string instead of using null. I believe that would work in the current setup as well, though I'm not sure how hard it would be to adapt it for that.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...