Please use the google group to ask questions - thanks.

by user2 07 Nov 14:56
What annotations are not supported?
19 Nov 04:06
by Rob


This is not used by Ebean in that if you specify via @Column a different table than the base table then Ebean automatically handles the defining of a Secondary Table and its join information.

19 Nov 04:07
by Rob


Used for DDL Generation. Ebean does not do this.

19 Nov 04:08
by Rob


This is currently not supported - and Enhancement request.

19 Nov 04:08
by Rob


This is currently not supported - and an Enhancement request.

19 Nov 04:10
by Rob


Currently not supported - an Enhancement request.

19 Nov 04:12
by Rob


Currently only supporting single table inheritance. This will be supported when the JOINED inheritance strategy is supported.

19 Nov 04:16
by Rob

@SequenceGenerator, @TableGenerator, @GeneratedValue

Hmm, Ebean is a little different here in that you should only need to use @GeneratedValue to specify any IdGenerator such as TableGenerator or UUID.

Sequences are used automatically by Ebean when needed depending on the Database (as alternative to Identity/AutoIncrement). Ebean expects a Naming Convention of Sequences and uses that to handle sequences automatically.

I'm almost expecting this part of EJB3 to be cleaned up in the next version.

16 Jan 19:14
by Alex

What about things like @NamedQuery? I take it, since the JPA QL is not supported, this annotation is also off-limits?

17 Jan 09:22
by Rob

Yes, currently @NamedQuery is not supported.

I haven't thought about supporting it without JPA QL. It may be possible...

I guess the related question is... when (how badly) do people want JPA QL support.

17 Jan 14:13
by Alex

I'd say, "badly enough" to make it one of the top priorities. Most ORM engines allow some sort of plain-text querying (as opposed to Criteria-based queries), and this makes it easy to write ORM-agnostic DAOs that could be reused while moving from one ORM solution to another. Criteria querying interfaces are not as portable, as they require some sort of ORM-neutral translation layer, while plain-text queries only need parameter binding facilities...

18 Jan 06:16
by Rob

Yup, OK. I'll have a look at it... I guess the things that will be most tricky are the group functions and subqueries. I'll have a dig around and do some thinking.

18 Jan 14:23
by Alex

I'd say, stick with supporting the simple ones first - that is, those queries that return lists of entities, as pretty much every DAO I've seen so far includes some kind of "List getByQuery(String query, Object... params)" interface, that makes things really simple. Things like aggregates belong more to reports and native SQL, I'd agree with you here.

18 Jan 14:24
by Alex

Also, what about the interceptor annotations - @PreInsert, @PreUpdate, and the like? Are they supported?

19 Jan 08:04
by Rob

The short answer is no - not yet.

Ebean has BeanController and BeanListener. BeanController matches the @Pre* @Post* of EntityListeners but to me there are issues with JPA EntityListeners.

In the past I have used BeanController @Pre* methods to enhance or override the IUD logic, and I have used the BeanListener to listen for cluster wide post commit events to maintain Lucene Indexes etc.

To me JPA EntityListeners are not designed for either of these tasks (although the examples suggest otherwise). So I wonder if people are aware of the issues involved.

I guess I could match JPA EntityListeners to BeanControllers but that assumes this is actually the behaviour people are wanting (which may be a reasonable assumption).

19 Jan 14:11
by Alex

Could you please elaborate a bit more on the issues with JPA listeners? We're currently using them for quite a bit of our logic (creation/modification audit; master-detail management for removed entities etc.), and it would help to be aware of any potential pitfalls...



21 Jan 08:28
by Rob

Q: Do @Post* methods fire before commit or rollback?
Q: If they fire before the transaction is committed or rolledback, and the transaction actually fails (and a rollback occurs) do you still get the event?
Q: If you are running in a cluster with multiple servers does a @Post* method fire if the event occured on another server in the cluster?

Depending on your situation (and the answers to these questions) it either matters or not.

For me in using @Post* type methods (to maintain a Lucene Index for example) I specifically do not want to get notified of events that where rolled back (inserts that didn't actually happen). I want to know about inserts etc from other servers in the cluster.

The way I read the JPA spec it seems like the @Post* methods occur prior to commit or rollback. Note that @Pre* methods HAVE to occur prior to the commit, and this issue does not seem to be mentioned.

In regards to @Pre methods. The issue here is there seems no provision for actually overriding (or extending) the IUD logic. So for me, if your bean is based on say a file or a spreadsheet etc and you want to override the IUD and Find behaviour - I don't see Entity Listeners providing this type of functionality.

In your situations the JPA behaviour may be ok. The spec section 3.5 suggests portable apps should not make use of EntityManager or Query operations in Callback methods (which seems restrictive). I guess you are trying to use the same transaction for your audit master detail delete etc. (With Ebean I make the Transaction explicitly available).

All that said, I could be interpreting the spec wrong as there is no explicit mention of transactions (and especially rollbacks).

22 Mar 20:16
by Eabin

@JoinColumn doesn't seem to work either. It does set the name param, but tries a dynamic match via the foreign keys anyways.

20 May 09:14
by Rob

The @JoinColumn should work... sounds like a bug. Can you provide any more details?

14 Jan 09:55
by Rob

@MappedSuperClass support is logged as a bug. I'm investigating adding support for that.

Create a New Topic

Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements