Hibernate 3.2.5:

hibernate-reverse-engineering-3.0.dtd:

Oracle 10g:

I’m working on the Hibernate reverse engineering file for HBM development. I don’t have any idea how to specify the second level cache development tag (<cache usage="read-only"/>) in the reverse engineering file(*hibenate.reveng.xml). Any help. If possible can you share some sample for the same.

Saravanan

we deliberatly don't since it is very often better to set thosethings up explicitly in your cfg.xml.

By using customized classes like DelegatingReverseEngineeringStrategy, Is there any way to modify or insert a new tag (<cache usage="read-only"></cache>) in HBM files. As per my requirement, I have to do second level cache only for selected tables not for all the tables

please reread my last comment.

So, you give us @org.hibernate.annotations.Cache to put on Entity beans, but deny us the possibility to make it persistent when regenerating those beans with reverse engineering...

I admit I can't see the point here.

pisce - it was *always* our recommendation to list things in cfg.xml when it comes to hbm.xml files and it fits nicely into the reverse engineering too.

When it comes to annotations it is a bit different, I would need to examine but i'm pretty sure it is possible to declare this externally too.

About what we offer and do not offer in reveng then there are two factors here:

1) if everything were configurable in reveng.xml it starts becoming equivalent to mapping and you should not be using reveng.xml

2) if you got an itch about something not being configurable and it can made to be so without breaking #1 please provide a patch

using the cache definition in hibernate.cfg.xml should work for annotations as well, if not this is a bug, open a JIRA issue.

Cache definition works with annotations as far as I tried it, you can even declare a cached entity in persistence.xml with the following (for a read-only cache strategy) and no annotation:

<property name="hibernate.ejb.classcache.<qualified bean name>" value="read-only"/>

My point is, all the mapping that used to take place is hbm.xml files can now be put directly in specific entity beans, thanks to JPA and Hibernate annotations, making it more comfortable to use and maintain.
You need to cache a bean, just put @Cache on the bean and you're done.

The only drawback of this cool practice is that entity beans are often maintained by regenerating them from the database. And nobody wants to manually edit entity beans each time they are regenerated.
So, you can avoid making hbm.xml files as I do, but not a reveng.xml file.

I'm aware that adding those possibilities will make the hbm and reveng format types very alike, but what if this is needed by your users (I saw several JIRA issues for this)? maybe reveng.xml files have become more critical than hbm.xml files since Java 5 and JPA are out?

Thanks for verifying!



My point is that "just put @Cache on the bean" is maybe too easy - the most common issue I bump into when doing consulting is that people is doing caching waaay to agressive.

anyhow..



yes.



Yes, but @Cache is an essential cornercase...especially since proper mapping of entities and their assocoations (lazy/eager/etc.) and proper collection types is *much* more important too look into before doing caching.

So we should at least get those things covered before adding good "caching" support to reveng.xml.

Care to contribute ? :)

OK, I see you have some bigger priorities ^^

I'd love to contribute to this point, as I sincerely think Hibernate would become more user-friendly with those features.

Don't have a clue about the contribution process though... does it go through a patch in a JIRA issue?

yes, patches goes to jira

Ps. If you include unittests then it gets applied faster.