MySQL JDBC Storage Method for WorldGuard Regions.

[narthollis]

I have spent the past few days working on this patch to add MySQL as a storage method for WorldGuard.

It has been quite a while since I did any coding in Java, so I am not entirely convinced of my code quality, and would welcome feedback to get this patch up to scratch for inclusion into WorldGuard.

I think for the most part the code is commented where it needs to be and self explanatory otherwise. If you have any question, please ask.

Additionally I can normally be contacted on IRC between 0900 and 1700 UTC+10:30 as narthollis. (I am presently in #WorldGuard on Esper.Net)

[TomyLobo]

can you run these commands:
git fetch
git reset --hard d1bd090
git rebase origin/master
git push -f master

this way, you get a linear history without merge commits.

I'll looking through the changes in a bit
but I can only give generic comments since I'm not familiar with the storage system

[narthollis]

Thanks for that TomyLobo, I have fixed the commit timeline as requested.

[zml2008]

I went and asked GoMySQL about this and he had a few suggestions:

zml2008, looks fine - though I'd ditch the UNIQUE INDEX.. on name and just define:: name varchar(##) NOT NULL UNIQUE,
Even the largest servers aren't goin to have more than a few hundred or even thousand entries - indexing won't offer any realistic benefit there.

[narthollis]

Thanks for the input zml2008. I have update the SQL to reflect the use of UNIQUE constraints rather than UNIQUE INDEX's.

The one other thing I was wandering about with the SQL was the length of the various varchar fields. Is 64 characters long enough for the user name, group name, world name and more importantly region name?

[zml2008]

64 characters is fine for player, but the others can be longer

[narthollis]

Is there anything else that I can/need to do to make this patch acceptable for merge into WorldGuard?

[zml2008]

It looks fine, someone just needs to test it and merge it. I'll be busy for
a lot of the next week, but the pull will probably be merged.

[markrobinson85]

I've tested this on Bukkit 1.0, and I get a few errors creating new Regions. I'm looking at the actual database and it looks like the cuboid values are being inserted in the wrong columns (Except on the first region created).

region_id min_z min_y min_x max_z max_y max_x
carpet -751 83 -2996 -750 83 -2994
carpetina 752 83 -3009 -750 83 -3005
carpeto -752 83 -3002 -750 83 -2999
KaeaCity -2514 17 -3051 -2160 127 -2705
Kitsilana 0 -2365 -2401 127 -1428 -1487
Marpole -2649 0 -3017 -1487 127 -2366

Kitsilana was the first region I created, and it appears to have been created correctly, but all regions after are inserting the coordinates into the wrong columns.

There is also a bug that frequently pops up, referring to the previously region created, saying:
"Failed to write regions: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'KaeaCity' for key 'Primary'.

I can look in the database and sometimes the new region is created regardless of the error message - other times it isn't. Reloading WG gets rid of this error message, but the message comes back again after a few regions are created.

[markrobinson85]

Now I'm noticing another part of the problem with the cuboid table. I'm not sure when it happened, but a good few of the columns looked like they organized themselves back to normal (first noticed after doing /wg reload):
region_id min_z min_y min_x max_z max_y max_x
carpet 83 -2996 -751 83 -2994 -750
carpetina 83 -3009 -752 83 -3005 -750
carpeto 83 -3002 -752 83 -2999 -750
dirt -2165 70 -2655 -2164 71 -2652
grass 71 -2702 -2175 71 -2698 -2171
KaeaCity 17 -3051 -2514 127 -2705 -2160
Kitsilana -2365 -2401 0 -1428 -1487 127
Marpole 0 -3017 -2649 127 -2366 -1487

But then, after defining a new region, the columns all shifted out of order again.
region_id min_z min_y min_x max_z max_y max_x
carpet -2996 -751 83 -2994 -750 83
carpetina -3009 -752 83 -3005 -750 83
carpeto -3002 -752 83 -2999 -750 83
dirt 70 -2655 -2165 71 -2652 -2164
grass -2702 -2175 71 -2698 -2171 71
KaeaCity -3051 -2514 17 -2705 -2160 127
Kitsilana -2401 0 -2365 -1487 127 -1428
Marpole -3017 -2649 0 -2366 -1487 127
small -2165 70 -2660 -2164 70 -2659

May be a problem with the insert statements.

[narthollis]

It would seams that I was creating the Cuboid Region vector points wrong. I have fixed this up in the most recent patch.

[markrobinson85]

Awesome, going to try it out. Will let you know if I find any other glitches. :) Love this modification, and want it to get pulled.

[markrobinson85]

It worked, regions are created normally now.

There is another small glitch I came across. When the plugin updates the config file with the new SQL options, it only adds:

sql:
    use: false

But doesn't add the other fields (I had to locate them within the sourcecode)
dsn:
username:
password:

[narthollis]

How the config file was created was something I wasn't sure of before now.

I have removed an if statement that will now allow these values to be populated with some defaults.

[narthollis]

Rebased my repository to orgin/master.

[TomyLobo]

we hang out in #sk-dev on espernet. join us there to discuss the pull request in a more instant fashion

[narthollis]

I have added some classes to deal with migrating too and from various region database backends. Presently i have implement YAML to MySQL and MySQL to YAML.

There is the framework in place to quickly add more converters as needed.