[WIP] DonutProtection: Plots and Project Worlds - Looking for contributors

[boformer]

I’m developing a new plot and world protection plugin for Sponge. I don’t know if “DonutProtection” will be the final name, but I like donuts

The plugin will be extensible and rely on a SQL database (later maybe other storage systems).

Some planned features:

• Basic support for Sponge permission system (e.g. donut.protection.build and donut.protection.build.plot.[x].[z])
• Inbuilt permission system (needed for worldedit support, member list, etc.)
• Manage plot and world access (e.g. build, buildredstone, worldedit, manage_players, owner
• limit worldedit to claimed plots
• Approval System for finished plots
• …

More features and concept info:

Creative Tools: WorldEdit for all players and Project Worlds

I will write some plugins for protection and WorldEdit limitation, specially made for creative servers. The ultimate goal is to give every player WorldEdit permission, so they can build whatever they want, but also to provide good protection. A have already made Bukkit plugins doing most of the stuff I listed here, but never published them, and some of them are still not done. If you have other ideas or suggestions, just tell me! Goals: Worldedit usage limitor Right now, WorldEdit causes a l…

---

I’m looking for contributors and people who can check my code for errors (especially in the DataManager, I hate SQL ;)).

Github:

GitHub - boformer/Proto: Plot and World Protection Plugin for Sponge...

[Kodfod]

I would suggest for you to allow for multiple data storage systems. (IE, MySQL, flat file, sqlite) This is just a little thing that I really hoped people would do, but didn’t (most of the time) in bukkit plugins.

[boformer]

It will be easy to add SQLite support, and later a file storage using HOCON.

Right now I want to focus on other features

[xxmarijnw]

I would suggest shorting the permissions a little. They are a bit long and hard to remember.

[Kodfod]

Also, something that I like to do for SQL statements is create a class that will house the variables such as:

https://github.com/kodfod/JavaTestDump/blob/master/src/temp/DonutProtectionPlugin/StatementVariables.java

and in the starting of the plugin add:

new StatementVariables(this);

Then instead of…

PreparedStatement statement = databaseConnection.prepareStatement(
    "SELECT name "
    + "FROM " + databaseTablePrefix + "worlds world "
    + "WHERE world.uuid = ?"); //1

Do the following

PreparedStatement statement = databaseConnection.prepareStatement(StatementVaraiables.getWorldDataStatment);

I find it a bit more appealing, Just my opinion. Some people don’t like it

[boformer]

2 questions, maybe you can help me

1. Do you see any mistakes in the SQL statements?
2. Regarding PreparedStatements:
   I know that I don’t have to prepare the statement again like I do now, I can re-use them.
   But what happens when the database connection gets closed and renewed. Do I have to prepare the statements again after that happens?

Also, I thought of using plain text or java properties files to externalize my sql statements. What do you think?

[Kodfod]

Right of the bat I can not notice anything wrong with your statements (just glancing, nor can I remember from when i ported all that over).

Prepared Statements are per connection. What this meas is if you have more than one connection to your database (or have to reconnect) you should make sure that the Prepared Statement is always using the same connection every time. If you have to make a new connection (due to time out for example…) you will need to recreate the Prepared Statement.

I personally don’t like storing such things out of vars, but that’s a design call really. But I would say not to do it strictly from preference, there my be people who say no for performance, or yes because why not?