Hi,

I have classes annotated using the standard JPA annotations. I want to add some additional, Hibernate-specific O/R mapping features (e.g. filters). However, I don't want to put Hibernate annotations in the entity classes. I'd rather put this Hibernate-specific metadata in a separate XML file, but still use the JPA annotations in the entity classes. Is this possible, and if yes, how to implement it?

why?

I'm not the original poster, but I can give a reason why I would want to do it: prevent my entities from being directly bound to Hibernate.

While if you're going to change out your ORM mapping implementation for a given project/workshop; you're probably looking at alot of work anyway, and changing the entity definitions would probably seem like a drop in the bucket. However, I would think that it is a reasonable goal: the less you are tied to a specific framework, the easier it will be to change when something else comes along.

I like Hibernate, and what it provides for me; I also like annotations and what they can do for me, however I know that the organization i work for will probably continue to use XML mapping rather than annotations. Because using annotations binds our domain objects to a ORM implementation--a specific configuration of one at that. However unlikely, and ah...poorly designed imho (must be PC now), it is plausible that I will want/need to map an entity in to different manners.

Now having said that: I wouldn't use annotations at all. Instead, use hbm mapping files. I guess a different question would be in this regard: can you annotate using JPA but use hbm files for the Hibernate information. Again, why would you want to? I don't have an answer for this one, as I wouldn't do it. I would just stick to hbm mappings and skip out on annotations altogether.


.. Which brings me to a question: I realize that Hibernate Shards requires Java5, but does it require that your entities are mapped via Annotations, or does the ShardedSessionFactory support hbm.xml mappings?

That's my two cents... thanks for listening.

-B

Portability.

Currently, using annotations allows mixing Hibernate and JPA features; thus, you can do both: comply with the standard, and use some of the advanced features that Hibernate provides. However, if you choose to switch to another framework, you'll have to comment the Hibernate annotations, or include hibernate-annotations.jar in the classpath, which is somewhat pointless.
Therefore, in order to achieve easy portability, XML should be used for O/R mapping. However, I don't see a way to mix up the Hibernate XML mapping files and the standard XML's defined by JPA.
I thought, it would be good if one could define O/R mapping using the JPA (either annotations or XML) and in addition use the tweaking capabilities of Hibernate, but without changing the JPA mapping.

Guys,
If you do not have hibernate-annotations in your classpath at runtime, it will be all good. The annotations will just be ignored by the VM, so the portability of your domain model is the wrong excuse: your domain model IS NOT BOUND to hibernate when you use annotations.

In case you want to move away from Hibernate, I actually find the annotation mode easier, you will know what is hibernate specific and replace it with your other provider specific annotations at the same place.

So we solved your end problems :)

As far as the annotations go, i know that if you don't have the worker classes in the classpath to process them, annotations are ignored. However, the second thing you pointed out is you'll know what's Hibernate and what isn't, and that makes it easier to replace. Unfortunately, this assumes that

1) You are going to use annotations from your new provider.

and the big one:

2) You're going to, or you need to, recompile your domain model code in order to reuse it with the new provider.

I'm not sure where I stand on #2, but i know where my organization does: I shouldn't have to recompile my domain model (entity classes) to get it to work with a new ORM provider. With Hibernate's mapping via XML support, i can create a domain model jar, and then create a Hibernate-based DAO jar which maps said entities to tables.

This discussion has been making me think about what practices are good/bad (for me in any event). While I like annotations for some functionality, i think that the use of implementation specific ones isn't a good idea. Doing so doesn't necessarily bind, but could describe them as being something they're not: hibernate based.

My two cents anyway, thanks for listening.

-B

Believe me, if you change your mapping from one provider to another, recompiling your domain model is the least of your problem.
Optimization strategies are different from one provider to another, so you will need a whole optimization phase before switching.