DB connection part of API or a separate Plugin?

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 …

I have a list of potential options here:

Unfortunately none of them really fit all the necessary criteria and we are not in a position to write an entire persistence ecosystem ourselves.

1 Like

While talking with @coelho in #permissionsex, we came up with a quick proposal for how Sponge could handle sharing basic JDBC connections between plugins. There could always be some sort of ORM on top of this, but this would help plugins take care of basic connection management.

17:56 @zml sponge was considering including a connection pool impl
17:56 coelho from how jdbc is implemented it is possible
17:56 coelho but they need to remember that someone might be using multiple DBs in different plugins.
17:57 @zml well, it would just shade the pool library into the API jar, then plugins would access it like normal
17:57 coelho I would like it if the connection pool was actually shared between plugins
17:57 coelho because what I see atm is that a mysql server for bukkit normally has a ridiculous amount of connections from other plugins and their own pools
17:57 coelho basically wasting resources on the sql server
17:58 @zml that could work, database connections configured in-api, then plugins acess those database connections (by name?)
17:58 coelho I would assume they would access it by driver, connection string, username, and password
17:58 coelho Or maybe there could be a config
17:59 coelho So it’s just driver and name of connection
17:59 coelho Streamline it a little bit more.
17:59 @zml could be like the JBDC URL
17:59 coelho well if we do it this way
17:59 @zml just jdbc:mysql://user:pass@host/database
17:59 coelho what we can have is a config in the main server directory with one sql config
17:59 @zml brb
17:59 coelho and then all plugins just reference it by name
17:59 coelho so you don’t have to c&p the same sql config into a thousand plugins.

Yes, your last point being the crux of the matter

DB connection would be so good to have by default!!

Some sort of ORM (Object relational mapping) system would be really nice.

1 Like