Java Persistence API / Ebean Server Support?

Plugins Plugin Development
1

I used Ebean Server of Bukkit a lot. (Java Persistence)
Is a similar system planned?
Ebean? Hibernate?

Improvements:

Links:

http://www.avaje.org/
http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-140049.html

4 Likes
2

I would recommand a lightweight persistance API, for example http://ormlite.com/. If you want to have a large database server with many relation, you can use hibernate. But for simple database communication a lightweight is sufficient enough.

2 Likes
3

Wow, I never saw those improvements. Too late now I guess :stuck_out_tongue: , unless sponge replicates the way bukkit had it.

4

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.

5

An extended opinion about JPA API in sponge:

The API will be widley use to persist simple object without large relationships. It has to be simple to understand and use, otherwise the devs will delevop own persisting mechanism (writing plain text or use JDBC API). It doesn’t matter, if the provided API is very fast or is providable to map every single SQL standard. Plugins, who are in need for managing complicated relationships or are performance critical, can include their own personal library. But this amount of plugins is small and providing a wide API would be the best for sponge.

I don’t know many APIs, only Hibernate, ORMlite and EBean. Hibernate is very powerfull and full of features, but very complicated. You have different ways to persist and load objects, using XML based or annotation based. This can confuse dev, who are new to Hibernate and JPAs concepts. I tryed EBean, but I dislike the need of writing full bean with hashCode and equals implementation. I like the simplicity of ORMLite.

1 Like
6

I never need that oO
For what did you used that?

7

I hit that one when using composite primary keys. EBean is reasonable but it’s got more than a few gotchas and the documentation isn’t great.

8

Maybe I’m wrong, but a few month ago, I tried to replace JDBC usage for a test plugin. I didn’t manage to get it run, and I remember, that I have to create a full bean, where I lost my motivation.

9

What did you mean with “full bean”
I used seperated DataClasses, e.g.:

that simple^^
(Ebean creates tables for me and grab the data^^)
Example repo:

10

Ok, don’t know I was try to do. Thanks for your clarification.

11

Ebean - SK’s Opinion: Extremely buggy
That’s right, it is really buggy. Don’t go for it.

I was looking at ORMLite yesterday, and it looks great.
There are nice samples, a good documentation.

It can create tables for you, but it can’t update them (like ebean). It should be possible to extend the system: link
It has a query system similar to ebean (simple to use), but with more options. Example: link

Before adding anything to Sponge, we should do a lot of testing. The main problem is that we need a dynamic system (add more fields when plugin updates, etc…).

Why do you think that Ebean was not easy for devs? the concept was great. the problem was: bad documentation and a lot of bugs.

I would say Hibernate is not easy for devs :wink:

12

I always though ORMs were a bad idea.

Initial development starts real fast but you end up spending more time fixing orm-related bugs and inefficiencies that you would have spent writing your own queries.

Not only that but your queries are never optimized which leads to major performance issues.

1 Like
13

Note that there are two ORMLites: the .NET one and the Java one.

14

I was talking about the java version of course :wink:
The second link in my last post works now as well…
link

15

I have to second this. As a technical architect that worked with J2EE in my Ernst & Young days, I had to do major surgery on some major applications that used “entity beans” to virtualize the data layer into the application server. The use of entity beans was disastrous.

The problem with all of these object to relational mapping models is that modeling the data-layer in the application server at the object level and then having a service layer creating fine grained connections to the database eliminates the optimization provided by the query engine on the database server. Essentially joins are done in the application server rather than in the SQL database server. (The general rule in database design is to do the heavy lifting as close to the data as possible to take maximum advantage of the query optimizer and indices.)

My knowledge of this may be somewhat out of date for the leading edge stuff, but the architectural issue of optimization remains. You just can’t get around it. In our applications at my company, which is .net and MS SQL Server 2008, we go the traditional route of data access API to stored procedures on the database server. (Why? stored procedures are compiled and the compilation is stored for reuse which speeds execution. Also, properly written stored procedures all but eliminate SQL injection attacks, which are a big problem with in line queries written in the application or presentation layer.)

Jim

16

I have to disagree, once you get the hang of JPA, DB integration gets much easier/straight forward. It reduces your code size and therefore time needed for maintenance and development. The EBean server in Bukkit worked ok for simple beans with no relations, but it is poorly documented and hard to debug (since so much happens under the hood, holds for every ORM). On the other hand I used Hiberrnate in JEE for quite some time and it usually works great as long as you don’t try to use very fancy features (inheritance, ordered lists, …).

Since many plugins need to persist data and a DB is probably the cleanest way (provides transactions/consistency, …) I would be really happy if there is some sponge ORM out-of-the-box support, preferably via JPA. But it is certainly a good idea to also allow devs to get a direct JDBC connection.

After googling around a bit I found this JPA performance comparison.

17

Is there a reason why EclipseLink is not considered?
I have to admit I never used it myself, but from what I read it is a pretty good JPA implementation. It is distributed under the Eclipse Public License(open source) which should be fine.

1 Like
18

EclipseLink looks very interesting …
Last release: July 4, 2014
active since July 08, 2008 …

But there must be a reason nobody has suggest it earlier …

19

I worked with EclipseLink. It’s awesome, it’s just hard to make it work without a persistence.xml (if you need that).
It follows the JPA standard, so there is a lot of documentation.

It also updates database schemes (when you update a plugin):

<property name="eclipselink.ddl-generation" value="create-or-extend-tables" />
20

Should be possible to get around persistence.xml, short googling delivered this stackoverflow post.
I suggest two ways to access databases from sponge.

The JDBC way:
plugin.getJDBCConnection() which returns a JDBC connection to a database for the specific plugin

and the JPA way:

plugin.getEntityManager()which returns the PersistenceContext (an EntityManager) for that plugin, thereby abstracting whatever provider is used.

Seems legit?