The Hibernate team have been working on improving the toolset surrounding Hibernate 3 core.

The current tool set for Hibernate 2 have been reworked. The new tool set for Hibernate 3 includes flexible template based code generation, a query console and a set of development wizards via our new Eclipse plugins.

Furthermore the Eclipse plugins contain support for reverse
engineering an existing database schema to a set of fully working hibernate mapping files - including configuration files and POJO's.

We have also released Hibernate annotations 3.0 alpha 2 with bugfixes and added features. Hibernate annotations adds support for EJB 3.0/JSR-200 persistence annotations to Hibernate 3.

The tool set is going to be improved and extended. The Hibernate Team encourage anyone who would like to contribute to the Hibernate Tools project to go take a look at this new release.

Discussion and possibly contributions of features occurs in the toolsforum and the development mailing list.

See more at tools.hibernate.org and http://annotations.hibernate.org

Looking at the example linked it doesn't appear that Hibernate makes use of the new java generics.


    @OneToMany(cascade=CascadeType.ALL,
               targetEntity="Order")
    @JoinColumn(name="CUSTOMER_ID")
    Set orders;


This looks a bit clumsy and not really in line with the generics. Instead I'd much prefer to see something akin to this:

    @OneToMany(cascade=CascadeType.ALL)
    @JoinColumn(name="CUSTOMER_ID")
    Set<Order> orders;

Not sure if this is possible with JDK 1.5 (with no reflection for generics) but it sure would be nicer than what we see in the example.

Looking at the example linked it doesn't appear that Hibernate makes use of the new java generics.

We supports and encourages the syntax you provide. Please refer to the annotations documentation
http://www.hibernate.org/hib_docs/annotations/

PS: this is natively supported by the EJB3 spec

Looking at the example linked it doesn't appear that Hibernate makes use of the new java generics.

We supports and encourages the syntax you provide. Please refer to the annotations documentationhttp://www.hibernate.org/hib_docs/annotations/PS: this is natively supported by the EJB3 spec

Neat. Howver, from the example that TSS linked to it's far from obvious that generics can be used instead.

As a matter of interest, how is this accomplished in Hibernate given that Java 1.5 doesn't support reflecting on generics' types?

Howver, from the example that TSS linked to it's far from obvious that generics can be used instead.

The sample is not "fixed", thanks.

As a matter of interest, how is this accomplished in Hibernate given that Java 1.5 doesn't support reflecting on generics' types?

http://cvs.sourceforge.net/viewcvs.py/hibernate/HibernateExt/metadata/src/java/org/hibernate/cfg/AnnotedElementInferredData.java?rev=1.6&view=auto
Check the findCollectionType method

Howver, from the example that TSS linked to it's far from obvious that generics can be used instead.

The sample is not "fixed", thanks

I wanted to say *now* fixed, damn fingers!

Howver, from the example that TSS linked to it's far from obvious that generics can be used instead.

The sample is not "fixed", thanks

I wanted to say *now* fixed, damn fingers!

I'm afraid your fingers have made one additional mistake (albeit a small one):

  @OneToMany(cascade=CascadeType.ALL")

has a quote that doesn't belong there.

Emmanuel,

According to the docs, you didn't remove the @OneToMany "bidirectionality requirement". Will this be the case in alpha3? Any time soon?
I'd really like to try annotations-based persistence (already working with Hibernate3) but above requirement really is a showstopper.

regards,

Messi

Emmanuel,According to the docs, you didn't remove the @OneToMany "bidirectionality requirement". Will this be the case in alpha3? Any time soon?I'd really like to try annotations-based persistence (already working with Hibernate3) but above requirement really is a showstopper.regards,Messi

Interesting you consider it as a showstopper: we believe an object model should almost always explicit the many to one on the other side.
Anyway, it will be removed as soon as the next EJB3 spec draft is released.

Emmanuel,According to the docs, you didn't remove the @OneToMany "bidirectionality requirement". Will this be the case in alpha3? Any time soon?I'd really like to try annotations-based persistence (already working with Hibernate3) but above requirement really is a showstopper.regards,Messi

Hibernate 3.0 core (as of yesterday) now supports unidirectional one-to-many associations on a not null foreign key (yes, for Lists and Maps and arrays as well as Sets). So it's now easy for this to be added to the annotations spec.


However, I am *still* not convinced that this is not the best way to represent your data model. I would definitely argue that the default and most natural mapping for a unidirectional one-to-many should be to an association table, not to a foreign key. (This is also supported in Hibernate3.)

However, I am *still* not convinced that this is not the best way to represent your data model. I would definitely argue that the default and most natural mapping for a unidirectional one-to-many should be to an association table, not to a foreign key. (This is also supported in Hibernate3.)

I don't mean to question your advice, but want to get a better understanding. Does your argument hold for all types of associations (that is including composites), or for simple associations only?

Annotations makes my eyes sour. Having used it (forcibly) in .NET for two years, I think it's a dead end. For extremely static, orthogonal stuff - sure. But for configuration? Not a good idea.

I hope xml mapping files will still be supported? 100% better than cluttering my business logic view (java source files) with schema information.

Also, I'd like my customers to be able to configure some of the mapping information (using home-grown tools where the user can click on the database product, etc, and we fix-up the mapping accordingly).

I'm not going to ship my source code for that purpose!

hbm.xml and annotations overrides will be available.

Is database schema generation supported when using hibernate3 annotations?

yes - no difference than having hbm.xml.

we still don't have a schemaexport ant task that does it, but it is just a matter of doing it.

Not being able to do database schema generation from annotations quickly becomes a major barrier of using the annotations. If you have the flexibility of defining your own schemas, like we do here, it seems like a no-no to use Hibernate annotations not having this feature in place, when XDoclet does. I hope this will be in place soon.

btw.: Has any of the XDoclet folks considered automating - or make it simple - to convert their existing support into annotations? If at all possible?

I hope xml mapping files will still be supported? 100% better than cluttering my business logic view (java source files) with schema information.Also, I'd like my customers to be able to configure some of the mapping information

The EJB3 annotation has be designed to separate the logical mapping information from the physical one.
You'll be able to override the physical part in a descriptor, while letting the logical one in your source.
I don't really get you on the following

(using home-grown tools where the user can click on the database product, etc, and we fix-up the mapping accordingly).

I don't really get you here. If it's "just" to allow DB vendor neutrality, then your ORM engine do it for you, no need to update the schema annotations here.

I don't really get you here. If it's "just" to allow DB vendor neutrality, then your ORM engine do it for you, no need to update the schema annotations here.

Because the ORM engine is not totally vendor transparent. Our issues include different key-generation strategies (we have to be explitic here), different fetch-depths (especially Sybase is troublesome here) and we even map collections differently due to varying performance characteristics (i.e. join vs. lookup, etc.)

I don't really get you here. If it's "just" to allow DB vendor neutrality, then your ORM engine do it for you, no need to update the schema annotations here.

Because the ORM engine is not totally vendor transparent. Our issues include different key-generation strategies (we have to be explitic here), different fetch-depths (especially Sybase is troublesome here) and we even map collections differently due to varying performance characteristics (i.e. join vs. lookup, etc.)

I would also like to add that we have to tweak hibernate considerably sometimes to get adequate performance. For rather complex models and queries, the default path just doesn't do it (we routinly have to hand-code certain parts.) No big deal - just shows that ORM isn't for everything.

Our issues include different key-generation strategies (we have to be explitic here), different fetch-depths (especially Sybase is troublesome here) and we even map collections differently due to varying performance characteristics (i.e. join vs. lookup, etc.)

key-generation: use GeneratorType.AUTO
fetch-depths: the fetch depth property is in the configuration file, not in annotations.
Mapping collection differently: humm, I still need to be convinced. The optimization here is directly involved by the collection contract (Java level), and by lazying it or not. I would not make such decision driven by a RDBMS implementation.

"key-generation: use GeneratorType.AUTO"

I know all about that => it makes the wrong choices... (we have specific requirements about sequences and hilo id's, etc, i.e. some product numbers cannot have "holes" in the sequence, etc)

but isn't it a bad idea to encode "business" info in the database key? If your database key is the actual product code or id or whatever and this is exposed outside of the database then you're setting yourself up for lots of problems in the future.

On the other hand, if this is a legacy database design, like some insurance DB schemas I've seen, then I feel your pain :)

On the other hand, if this is a legacy database design, like some insurance DB schemas I've seen, then I feel your pain :)

99.9% of the databases I deal with in the Telco industry is "legacy" and 80% of these have business knowledge in one or more primary key. It's just the way things are done.

It should be the way things "were" done :) I'm certainly not going to get on my high horse about it though, we all have to work with stuff we're given, and would like to change, form time to time.

Annotations makes my eyes sour. Having used it (forcibly) in .NET for two years, I think it's a dead end.

Goose-gander. I've seen shops that prefer and use a total XDoclet for their EJB stuff. Even for configuration. What it usually is, is that they want to see everything in one place instead of having to look in XML files for how things are done. Then there's people like you who hate them...

Bill

Annotations makes my eyes sour. Having used it (forcibly) in .NET for two years, I think it's a dead end.

Goose-gander. I've seen shops that prefer and use a total XDoclet for their EJB stuff. Even for configuration. What it usually is, is that they want to see everything in one place instead of having to look in XML files for how things are done. Then there's people like you who hate them...Bill

We used to be one of those shops (JBoss + xdoclet, totally.) Then came reality and customer-specific branches...

Again, I must add, I don't totally hate annotations; it has its uses.

I just happend to think that putting *configuration* settings in compiled source code is an exceptionally stupid idea.

What's wrong with putting configuration into source as a "sensible default"? I have no problem with it as long as it can be overriden from the outside (e.g. XML config, system properties).

What's wrong with putting configuration into source as a "sensible default"? I have no problem with it as long as it can be overriden from the outside (e.g. XML config, system properties).

Well, since you anyway have to support settings "from the outside", you might as well use that *one* way of dealing with config settings.

Watch out, or annotations will bite you.

What's wrong with putting configuration into source as a "sensible default"? I have no problem with it as long as it can be overriden from the outside (e.g. XML config, system properties).

Well, since you anyway have to support settings "from the outside", you might as well use that *one* way of dealing with config settings.Watch out, or annotations will bite you.

This sounds like a very sensible and insightful comment. Having only *one* way of defining mapping configuration will also mean that users don’t have to learn two different ways of doing the same thing. It will save them from the inevitable and frequent confusion, subtle bugs, and frustration caused by the otherwise overriding behavior of XML over annotations. The reduced complexity will also help the tools and infrastructure vendors.

But it is doubtful that the movers and shakers would listen to these arguments because they are already too much invested in this idea of annotations for everything. Annotations for mappings would most likely be forced down our throats.

Then came reality and customer-specific branches...

XDoclet happily grabs variables from ant http://xdoclet.sourceforge.net/xdoclet/using.html

where they come from customer-branch-release specific property files.

Works like champ:
default build.properties has all the sensible defaults and by specifying -Drelease=some.properties we can override all _necessary_ properties. Ant just loads ${release}.properties BEFORE build.properties.
Net result is very convenient: big build.properties and small some.properties