SQLibrary
I would highly suggest using Bukkit's plugin databases API instead of this plugin.
SQLibrary
SQLibrary was taken over from alta189 by PatPeter. So far it has support for 13 databases, a factory, and one query builder.
Tutorial
First, add these elements to your pom.xml if you're using Maven:
<repository> <id>dakani</id> <name>Dakani Nexus Repo</name> <url>http://repo.dakanilabs.com/content/repositories/public</url> </repository> <dependency> <groupId>lib.PatPeter.SQLibrary</groupId> <artifactId>SQLibrary</artifactId> <version>7.1</version> </dependency>
You should always save implementations to a superclass, unless that child class has more functionality. So, start off by creating your variable:
private Database sql;
Constructing your database object can be either hardcoded into the definition, or assigned in the method. The constructor does not automatically open the database connection so that it does not have to throw an SQLException (though this was considered for quite some time). Below are the constructors for the most popular databases: MySQL, SQLite, and H2.
sql = new MySQL(Logger.getLogger("Minecraft"), "[MyPlugin] ", "localhost", 3306, "myplugin", "minecraft", "password1"); sql = new SQLite(Logger.getLogger("Minecraft"), "[MyPlugin] ", this.getDataFolder().getAbsolutePath(), "MyPlugin", ".sqlite"); sql = new H2(Logger.getLogger("Minecraft"), "[MyPlugin] ", this.getDataFolder().getAbsolutePath(), "MyPlugin", ".h2");
For SQLite and H2, the extension is optional but will default to ".db". For MySQL, the hostname and port number are optional, but will default to those values. Next, we need to open our database connection:
if (sql.open()) { // ... }
If you know that your plugin will only use the database intermittently, you should check to see if it is open first:
if (!sql.isOpen()) { sql.open(); }
If any errors occur while opening the database connection, they will print to console.
Supported Databases
- Firebird
- FrontBase
- DB2
- H2
- Informix
- Ingres
- MaxDB
- MicrosoftSQL
- MySQL
- Mongo
- mSQL
- Oracle
- Ovrimos
- PostgreSQL
- SQLite
Installation
- Download the jar.
- In Eclipse, go to Project Properties ==> Java Build Path ==> Add External Jar and add SQLibrary.jar.
- Tell your users to install SQLibrary.jar along with your plugin
Do not install from source!
If you install SQLibrary directly into your plugin, the following bad things will occur:
- You cannot run your plugin alongside SQLibrary.jar plugins. Bukkit will (usually) find the SQLibrary classes in your plugin first, and block the SQLibrary.jar dependency.
- You cannot run your plugin alongside other plugins using SQLibrary directly from source. Same issue.
- Updating will definitely cause these problems and cause you much pain.
Download SQLibrary from your plugin
You can now place this code in your plugin to download and load SQLibrary from your plugin at runtime:
http://dev.bukkit.org/bukkit-plugins/sqlibrary/pages/soft-dependency-download/
Special Thanks
- alta189, for starting this library.
- Belphemur, for adding the first version of our factory package.
- omwah, for adding Maven to SQLibrary.
- moose51789, for adding Spout support.
- Mitsugaru, for hosting our Maven repository, finding bugs, and making fixes.
- max9403, for supplying the code to download SQLibrary at runtime.
@ferrybig
No examples because it doesn't work for my requirements (a MySQL user with no password). Sorry.
Wonder if this has been fixed yet..
@Mr_Wired
The latest one is working with my 1.5.2 builds.
Will the 1.4.7 version still work with 1.5.2? Or do I have to wait until this is updated first?
@omwah
I will make sure to check out shading classes, but as you said, this method adds a bit of overhead to eliminate SQLib conflicts between plugins. I know that there were two methods before but I honestly found that redundant to begin with. As I said, my preference is that there is one method and that method is completely abstracted from the developer and with minimal developer action (as I believe all code development should be).
I think the notification to BukkitDevs was a decision that should be made by the library's developer. With this aim, I believe it will help to shift minimal maintenance to end users, help lower development overhead on PatPeters, and help minimize development overhead on our end. I currently have 7-10 plugins that haven't been published. If I had to keep updating the class files for each plugin, and for each dev build of bukkit, it would take forever. Sure, it could have used a bit of a more definite notification, but he notified everyone about it on his thread to switch to the JAR. As I said, the discussion to the bukkit thread was to enforce this change to eliminate the support of the class files in one easy swoop. http://forums.bukkit.org/threads/lib-sqlibrary-database-wrappers-for-all-database-engines.33849/page-13#post-1568857
@deleted_7151878
Right, a bug bugs everyone. That's unavoidable though. I'm going to pull out a vault api and bukkit api example despite you guys not wanting to compare to it. If there's a bug in either, the best you can do is ask your end-users to wait or downgrade. On the other hand, you can push code onto GitHub yourself (not sure about PatPeter's setup). If PatPeter decided to just stop development, then just like most developers and his last predecessor did, he should give the development responsibility to someone else.
While the flexibility to fix bugs in the code is awesome, if you find a bug in the code, the code change isn't automatically packaged and sent to all other users of the library. Sure you can post it on a forum, but I'd have to manually make a change on my end. You still have access to the source code on your end, so you can make changes, and test it on your end without uploading it to bukkit. Then as you said, report it to PatPeter to release an expedited update. I've seen other developers of large plugins helping with the transition by requiring the JAR dependency.
In addition, I personally don't release my source code for my privacy reasons and I expect others to kindly respect that. I respect that PatPeter made his decision to centralize one method of access to the code.
@adenslayer
I'm glad that you are working on a custom library to avoid this but as I said, adding additional class files is a hassle for me, for a lot of developers, and end-users so I will be sticking to the best JAR solution I can find and atm it's PatPeters until I find anything better.
A$$hole!
http://dev.bukkit.org/server-mods/bookshelf/files/25-book-shelf-v2-7-1-5-2-beta/
"BookShelf now requires you to also download SQLibrary from here and put it in your plugins folder.
Sorry it has to be that way. PatPeter, (the now-owner of SQLibrary, the library BookShelf relies on for its databases) has informed the BukkitDev staff that he does not want developers including his class files into their plugins, and instead they all must depend on his plugin. This means you are now required to download his plugin and install it if you want BookShelf to work. I am working on a custom library to avoid this, but until then, if you want to complain and tell PatPeter how inconvenient this is, feel free to write on his plugin wall here.
If you get an error when starting bukkit along the lines of "NoClassDefFoundError," this is because you have not downloaded and installed PatPeter's SQLibrary plugin."
@krisdestruction
You're right, it does make issues less common between plugins, but omwah has a point. If PatPeter was to release a bug in his code which managed to screw up all of our plugins, that would be a big problem. And if PatPeter decided to just stop development, suddenly all of our developers are, as you say it, left in the dark with an issue they can't fix on their own without being rejected. This is just one reason I like using the source more than a jar; if I find a bug in the code, I can simply fix it, no problem. In fact, I was able to fix a bug in SQLibrary and report it to PatPeter so he could change it for all his users when I had the source, and now I can't do that. I think this change in policy is not only harming the developers and users of this library, but PatPeter himself as he no longer has an army of code monkeys to fix all his bugs, and he is losing support from major plugins. I constantly have people scanning through the source of BookShelf and fixing things for me. I would do the same for SQLibrary, if I could.
@krisdestruction
I disagree in your comparison to Vault. Vault is meant for plugins to communicate with each other and hence needs to be loaded separately. This plugin is just a wrapper around JDBC. If you use shaded class files then there is no possibility of conflict. Please look more into shading as it avoids your claims of issues with compatibility. Using shading is not easy, it takes a bit of effort and setup on the part of the developer to learn. The very reason people use shading is for maintaining compatibility. It could be argued that shading is far better for compatibility, because if SQLibrary changes its interface, it will break every plugin that has not been updated yet. If the plugins included a shaded copy then they would continue to work fine.
Furthermore, I think many of us are upset because of the way this change in procedure was done behind our backs. At one time this page showed two ways to make use of SQLibrary, and one of which was to include a copy. Don't believe me, then check the Internet Archive. I see no mention here on this page of the change in policy, it was just quietly updated to remove the alternative installation method. So when we update our plugins in good faith we get them denied. There was no warning, just a flat out change in policy. His licence indicates that redistribution is fine and there is no information on the Github page in either direction. The sneaky way this was done makes me loose my faith in the developer and come to the decision that in the long term it is in my best interest to avoid SQLibrary.
@deleted_7151878
I disagree, I develop using SQLibrary and several other developers use them for their plugin as well (ReportRTS and Minigames). SQLibrary is similar to Vault in that it helps developers interface with another component flawlessly, in this case different SQL instances. Without a standardized and updated API, developers are often left in the dark with update issues and end-users with compatibility issues.
While it might seem like it's easy to include the class files, admins like me (or your 10000+ users) also suffer with end-user compatibility issues.
@omwah
That's what I plan on doing. Maybe I'll create a little api for SQLite and MySQL and release it as open source for everyone :)
@deleted_7151878
I ran into this same issue when I tried releasing an update to my plugin. I was denied because I had included a copy of SQLibrary as shaded class files. Well, guess what? I no longer use SQLibrary because of this. I went through and changed my SQL access to use JDBC directly.
@modwizcode
I agree with this. I have to make all of my 10,000+ users now include another plugin if they want to use mine, when half the time, my plugin is the only one which even uses SQLibrary, and it would be much more efficient to just include the classes. My most recent upload was denied because of PatPeter's block of class files. It's pretty ridiculous. I plan on finding another library or even creating my own.
@krisdestruction
Violating the terms of your licence is technically against the law, but that aside the class files were shaded into the plugin, they naturally will not interfere with properly coded plugins as the files have a completely different location on the classpath due to a separate package. That's up to the person writing the plugin, not the person supplying a library. The main issue is that he instructed bukkitdev staff to not allow use which was within licence parameters.
@modwizcode
I could really care less if he violated the terms of his license. On the contrary, I support his decision to use the JAR instead of the class files. The class files in individual plugins cause conflicts between plugins which use the same class. Moving to using the JAR also reduces server usage of resources thus improving performance.
If you want to support clean development, don't use this plugin!
People, do not use this library. The author has violated the terms of his licence and has not allowed people to package this with their plugin by shading class files. The author also asked the bukkitdev staff not to allow people to include his classes in a plugin, meaning that anyone who uses this library creates a lot of extra work for the server owner. Making it much less likely to be added to a server.
@ManBeastPigDev
Yes, just drop the jar into the plugins folder and you are good to go.
I came here from http://dev.bukkit.org/server-mods/claimcontrol/
Do i just drag and drop this in with his plugin? I really dont want to tie in any in-game plugins with my servers sql daemon. I'm using it for a website i also host and dont want to mix them.
@gdude2002
I can verify that mysql dont always need a password by this:
https://dev.mysql.com/doc/refman/5.5/en/create-user.html
Also, do you have examples of this library, still confused how to execute a query
@krisdestruction
That's not actually correct; I have MySQL set up to not require a password for root when connecting locally (As I'm the only one who has access to the server anyway), and plenty of plugins that don't use SQLibrary work fine with that configuration (Empty string for a password). Gotta be something with that.
Also, create an account? You mean a database? 'cause that should always be done beforehand anyway..
@lordsill
Can't you just use?
hi, i get always the same error:
Caused by: java.lang.NoSuchMethodError: lib.PatPeter.SQLibrary.Database.isOpen()Z
every time, if my plugin use the sql.isopen() function.