DB connection part of API or a separate Plugin?

I’d like to see a ‘universal database’ type API. Something were I can set up the connection parms to my database (mySQL, SQL Lite, or whatnot) and then this be used by all other Sponge plugins. This way if I move my db or set up a new one I don’t have to remember which plugins have their own db config section.


I generally agree with this. However, I’d like to add a request to require a table prefix from a plugin so that tables can be more easily associated with a plugin in the database.

PLEASE DO THIS. I WANT THIS SOOOO BAD!!! I really hate having to edit like 10 diff configs for mysql.

Yes, each plugin needs to havr their own prefix and whatnot, that would be good.


It’s not really something that should be forced on other plugins but allow them to use that if they want to(To set a common connection for the plugins to use.).

Great Idea I fully support this, Even though this is an API this will make things so much easier.

I don’t mean to ‘force’ anyone. If you want to have your plugin write to a separate db you can. I just think it would be nice to provide this as an API so devs don’t have to worry about the db connection stuff IF they don’t want to. AND it makes it much easier for the server admin to change things when needed.

1 Like

I agree that it would be a nice thing to have, but it would have to be a bit more feature rich than the one that is currently in bukkit for it to be widely used. Of all the plugins that I have ever used, I’ve only seen one that actually used bukkit’s persistence database, and that one was buggy when you tried to use mysql on it. The one in bukkit was pretty much only designed mostly for usage with sqlite in mind by what it seems.

Ebean was very great (not the best option), but very good.
The problem is, that not much people are familiar with the Persistence Annotations …

btw. I use MySql as backend … never had problems …

Ebean was fine at best, I had issues with it so often, there needs to be an API included in sponge that allows a universal database access, this would be incredibly useful to programmers.

I could never make any sense out of the ebeans server.
I’ve also never actually found any plugins that use it :expressionless:

I did find quite a few plugins that used it and I even used it at some points but it was a very inelegant solution.


Can you describe your problems?
Maybe in the ebean thread:

Sorry, the vagueness was on purpose because I find it really hard to describe the exact problems I had, it was quite a long time ago that I worked with ebean and I just remember being frustrated at some of the errors it gave one specific one being.

javax.persistence.OptimisticLockException: Data has changed. updated [0] rows

While I eventually solved these issues ebean kind of left a “bad taste in my mouth”

Thrown by the persistence provider when an optimistic locking conflict occurs. This exception may be thrown as part of an API call, a flush or at commit time. The current transaction, if one is active, will be marked for rollback.

Without code it is impossible to say what happen …
Normally this is a usage problem …
The Exception normally prevent your to send outdated data to the server :wink:

Yeah, I eventually figured out a workaround by reorganizing my code a little bit and I solved the problem. I did know what the problem meant but for a while I couldn’t find for the life of me where the problem was. I am fine now though.

Honestly a storage manager in the API would be nice. Let you use generics for accessing storage and then you just configure it to use whichever storage system you want wether that be MySQL, NoDB, Mongo, flat file, etc.

Though I can also see the call for this being an outside plugin/api and not built into the sponge api as well.

Wouldn’t mind seeing the JDBC drivers for sqlite/mysql either shaded or easily added without each plugin needing to provide them inside themselves.
ORM’s are ok, especially for “simpler” schemas.I’ve never found one that can easily evolve alongside a project without having to nuke the old data or directly poke the db prior to loading (which kinda defeats the purpose of using an ORM to avoid worrying about database details).

Maybe the storage driver can be a module or SpongeExtra Plugin …