Hi,

Is there anyway to get the associated table name for a given persistent class? A part of my application requires a mass update where I need to make my own sql calls and I would like to abstract this to a number of similiar entities.

thanks,

josh

I found the following object navigation:

net.sf.hibernate.cfg.Configuration
net.sf.hibernate.cfg.Mappings
net.sf.hibernate.mapping.PersistentClass
net.sf.hibernate.mapping.Table

thanks, I also found the following works:



this way I don't have to hold a reference to the configuration object...
However, it makes me a little nervous. Any reason I shouldn't do this?

type casts from API classes to internal implementation classes should always make you nervous.

Good point. It also makes me a little nervous holding on to the Configuration since it says in the documentation:



I would suggest adding table name to the meta data api, but I have a suspicion this would open up a can 'o worms that is very purposely sealed tight.

a little background on my problem:

I am refactoring a bunch of application code to use hibernate. some of the database tables use the [url]Modified Preorder Tree Traversal Algorithm[/url] which is a way of ordering hierarchical data that is optimized for lots of reading and not so much writing. What makes it not so good for writing is that you need to do a batch update everytime you add something arbitarily to some point in the tree. Anyway, got it working well with one entity (using some batch update sql code) but would like to resuse this code for other entities...

And the reason I am rambling on is... I am wondering if there is some way to encapsulate this behavior at some lower level in hibernate that is not documented but is perfectly acceptable api usage. Otherwise, maybe I should just bite the bullet and cut-and-paste...

It is just a statement of intention - not a "You are not allowed to keep configuration around"-disclaimer ;)

There are no problems in keeping a Configuration around if you want to - you could also just extract the information you need and keep it some for you application better structure....



Yes - we are not very keen on unwinding to much of the SessionFactory metadata API....you should view the SessionFactory metadata as a compiled and "denormalized" version of the metadata available via Configuration..

So, if you can manage your problem with SF metadata then use that - if not, then use the metadata available in Configuration.



hmm - if you could show us what the code you don't like cut-and-pasting are doing then I think we can answer that waay better ;)