Spongeapi: Provide a default database connection trough the SqlService

[Eufranio]

Atm, the SqlService is only useful for getting a pooled connection for a separated database. It would be nice if it had a default, ready, database that plugins could use, like a Sponge.db. So, to get a new connection, we would just use service.getConnection() or something like that. Optionally, server owners could be able to specify the type of the connection (mysql, sqlite, h2) in the sponge config. With that, if more developers hook into the SqlService, we would have less stress related to a lot of SQL connections opened in the server for every plugin.

[Defman]

I dont see the need for a default connection, this could be solved by custom plugins. The idea of the Services and SqlService as I see it, is to allow a single plugin to controlle the connection pool and other plugins can hook in to it by using the SqlService.

I might very well be mistaken but that my thoughts.

[Eufranio]

Then you would need one main plugin to provide the public connection and others would have to hook into it. By having a default open, public database, we wouldnt need to have this custom main plugin.

[gabizou]

Personally I don't want to go down the route of offering a default service, much like the h2 db service bukkit provided. Not sure how @Zidane or @SpongePowered/developers feel about it.

[JBYoshi]

The problem of offering a default database service is determining which databases to support.

On the one hand, users would (ideally) want to get support for their favorite SQL implementation out of the box. If we support MySQL, SQLite, and H2, why not PostgreSQL? Why not Microsoft SQL Server? Why not DBYoshi (besides the fact that it doesn't exist)?

On the other hand, we shouldn't bloat the download size with unnecessary code. There was some discussion about this some time ago with thefastutil library (https://github.com/SpongePowered/SpongeAPI/pull/1708), and we decided not to include it because of its size.

[ryantheleach]

I also feel like it's better to keep fragmentation down of where server data is stored, which is what happened on Bukkit, with no sane migration path for the average user.

I believe this is one instance where it's better to have a slightly higher barrier to entry, in exchange for easier maintenance down the line for admins.

Closing for now.