Please use the google group to ask questions - thanks.

@SecondaryTable

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.

@UniqueConstraint

Used for DDL Generation. Ebean does not do this.

@AttributeOverride

This is currently not supported - and Enhancement request.

@AssociationOverride

This is currently not supported - and an Enhancement request.

@Enumerated

Currently not supported - an Enhancement request.

@PrimaryKeyJoinColumn(s)

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

@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.

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

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.

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...

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.

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.

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

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).

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...

Thanks,

Alex

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).

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

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

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