Please include database drivers into the API by default. e.g. H2, SQLite or MySQl / Maria.
3 Likes
Hmmm, Good idea I guess. But not sure if this is something an API has to handle.
Why, though? Java has native support for SQL, which is ridiculously simple.
EDIT: To expand upon my opinion; I do see the convenience of having a more simple way to process this. But it seems like something pretty silly to include when it would just bloat the API, and is simple to do ourselves.
Will your example work even when the server jar doesn’t include MySQL? Craftbukkit included the MySQL driver in their jar. (It’s what I was told) If your code works on Glowstone, then it doesn’t need the driver.
The main reason is to include a well documented database driver for everyone. Every mod who needs a database should use the same engine for a better administration. It will also reduce the “How do i install XYZ engine” posts.
W-wut?
You can see right in the imports I’m using java.sql.
import java.sql.*;
EDIT: Not to mention that that class doesn’t use Bukkit code or imports anywhere, anyways.
EDIT2: Unless you include the getConfig() methods.
Java already has well documented code for any type of database.
We already have methods available to us for databases. Including it in the API would just bloat it, create confusion, and eventually inspire debate about whether or not you should use native libraries, or the API.
Java has an API to work with JDBC drivers. You would still need to have the actual JDBC driver to be able to do anything with it. E.g. for MySql you need the MySql jdbc driver and for Sqlite you would need the Sqlite JDBC driver.
By default those drivers are not present on the system nor in the classpath.
I really think that Sponge should include those. (Glowstone doesn’t by default and IDK about Forge.)
This is not about creating a completely new API for database access, but to include a default db driver and pushing db configuration to the implementation instead of per plugin. You would still use the normal Java JDBC api to work with the database. The only difference is that you don’t manually make a connection, but get one from the API.
Honestly, I don’t think SQL is simple. The normalisation 
! I am still afraid of using SQL for plugins. It simply don’t know how to use OO with SQL.
While you’re not wrong, you would still need to do this regardless of whether or not Sponge has a built-in method for developers to use. It would still, in the end, be using JDBC.
I really don’t understand what you mean, here. Would you mind explaining what you mean in more detail? 
And, hopefully, with methods to close() those connections, as well?
Then learn it. SQL is simple, if one takes the time to practice using it, and read a doc here or there.
I would not want a database api to be included in the Sponge API itself. With a JDBC driver it is very easy to communicate with databases if you want. And then you are able to write your own little API if you need it.
And if you want to use an API, make it yourself and share it with the world.
1 Like
You see Ferus, in my plugin I import java.sql.*; and then later I have this for the connection :
if (PlotMe.usemySQL) {
Class.forName("com.mysql.jdbc.Driver");
conn = DriverManager.getConnection(PlotMe.mySQLconn, PlotMe.mySQLuname, PlotMe.mySQLpass);
conn.setAutoCommit(false);
} else {
Class.forName("org.sqlite.JDBC");
conn = DriverManager.getConnection("jdbc:sqlite:" + PlotMe.configpath + "/plots.db");
conn.setAutoCommit(false);
}
This code will crash on Glowstone because default glowstone does not include MySQL and SQLite drivers. Your “simple” example code will do the same thing.
1 Like
Including a default driver in sponge would make it easier for the developers. Developers would know for sure that that driver is present and they would not need to include any other drivers(or instruct end-users on where to put the drivers).
As I said, this is not about building an abstraction layer on top of Java’s sql classes, but about moving connections and configuration to the sponge implementation. Meaning that databases and their connections are not defined in the configuration of every plugin that needs it, but that that is defined in the sponge config. That would make it easier to configure for the end users, as well as easier to use for the developers(no need to do config loading, no need to check config, no need to check if connection failed, etc).
EDIT: Just to clarify, adding a small connection API is not what the original poster asked. He just wants to have a default DB driver available that can be used. IMO it would be better that if they do include a DB driver that they then also would make a small DB connection API to reduce the amount of connection boilerplate and config(for both developers as well as end-users).
It would still be a normal java.sql.Connection… So yes, it would have a close method.
I feel like including a connection pool (like BoneCP or HikariCP) would help plenty of developers avoid novice mistakes, possibly lead to a plugin reloading system, and would be generally nice to have for JDBC apps.
My idea was to include a standard Driver for everyone and maybe build a wrapper for the plugins like the configuration framework in forge, so every dev have to use the same engine and maybe the same database with a data space and a configuration space for every plugin. Under this condition the sponge team can build an “Admin tool” to set the configuration for the plugins and the plugin developer are getting the possibility to read values from other plugins to integrate the own plugin as good as possible.
The Sponge API is close to vanilla as possible. I do agree this can still be vanilla but like @thomas15v and @FerusGrim said. Whats the point? Java has native support.