Q&D Database Diffing Tool

[Tabasco]

This is something I came up with a while back when I was looking at the daunting task of migrating to the latest PEQ database while keeping my customizations. It's kind of nasty to look at (the source files in particular) but it does work.
It's all PHP but should run on LAMP or WAMP with appropriate database credentials.

http://216.49.224.132/eq/dbdiff.tar.gz

[revloc02c]

the daunting task of migrating to the latest PEQ database while keeping my customizations.
I am not trying to derail the thread (although it may happen :D ), but this is something I have really been wondering about for a while. What do people (you guys) do to reconcile differences between their own db customization, and the lastest version of the PEQ db. Are most of you just running the update scripts one by one (and hoping all is well)? Are you making your own scripts (of your custom stuff) and running them on the newest db version? Are you somehow separating you data and dumping it to a SQL file so that you can source it into a new db version? Or are you just ignoring the latest version ("who cares about that PEQ stuff, my stuff rocks!")? Apparently Tabasco has developed a db diff merge program of sorts (sorry Tab, I am sure it's wonderful, I am just not wanting to set up a php server right now to use it), is something like this what you are generally using?

[Robregen]

I did check out this and looks to be really nice tool to use for merging. putting the folder in htdoc folder in xampp directory works well.

[Tabasco]

It's trivial to set up and thoroughly worth it. A lot can be accomplished with SQL scripts but significantly more can be accomplished with a scripting language that easily integrates with your database.
On linux? Use yum or apt. Windows? http://www.wampserver.com/en/

With as many issues as a server admin faces I can't imagine not having some kind of command line scripting language available.
As an example that's more in line with your question, one of my biggest content changes is level-scaled world loot using the entire PEQ items table. It's all a set of scripts that I can run on a fresh database to score and distribute whatever items are in that DB release.
I also have some NPC and item libraries in the works for the purpose of automatically fixing ID's in the various spawn tables or quickly identifying and resolving item conflicts by overwriting or re-inserting and returning the new ID's.

Ideally I would like to define all of my content in one main script file using objects that can at least generate the appropriate new insert SQL and return ID's Then all I have to do is update my quest scripts. From that angle I could make a quest plugin that translates all my custom items by short name to ID, and then my script can just update the custom item plugin and all the quest scripts can reference $items{'fancy_helmet_1'} instead of 119899.

By the time I realized what I should have been doing to track my custom stuff, I was already pretty invested, which is why this tool exists, but moving forward I don't see a good way to future-proof your content without custom software of some kind.

[blackdragonsdg]

I am not trying to derail the thread (although it may happen :D ), but this is something I have really been wondering about for a while. What do people (you guys) do to reconcile differences between their own db customization, and the lastest version of the PEQ db. Are most of you just running the update scripts one by one (and hoping all is well)? Are you making your own scripts (of your custom stuff) and running them on the newest db version? Are you somehow separating you data and dumping it to a SQL file so that you can source it into a new db version? Or are you just ignoring the latest version ("who cares about that PEQ stuff, my stuff rocks!")? Apparently Tabasco has developed a db diff merge program of sorts (sorry Tab, I am sure it's wonderful, I am just not wanting to set up a php server right now to use it), is something like this what you are generally using?

I write all of my custom content into sql files that way I can source it into any future database with minimal headaches. I've only encountered significant problems twice in the 2 years or so that I have been around this project and both of those times could have been avoided with a bit more planning on my part.