dlmiles wrote:
But I too can see me wanting to face this issue in the future, in my situation I can describe the object relation ahead of time with a group of dummy tables but need to just change the name of the table(s) on the fly that would map together.
I'm saying in a perfect world it would be nice to be able to teach Hibernate about an ABSTRACT object relationships from a generic mapping group, then on the fly turn abstract into concrete by assigning all the specific things it needs to know in order to make that transition. In this example table names would need to be assigned.
This would open the door to allow set realtionships to be created on the fly that resolve to a group of tables.
To use Hibernate at this time you describe your fixed mappings ahead of runtime use, since the creation of a SessionFactory is mandatory to use Hibernate and the processing of mappings isn't trivial. It takes an order of time to compute. This makes it somewhat difficult to realistically use dynamicmappings known only at runtime.
If the infrastructure for the above was in place then that would naturally lead a path to making dynamic temporary tables very usable feature/tool to the application programmer.
At this moment in time the best solution I can advise you is that if you can describe in mappings your temporary table(s) with fixed table names and column names/types. Then make your applications CREATE/DROP the table as necessary (maybe with JDBC) around calling hibernate functions to do work on them.
// Create SessionFactory
// Don't touch any relahionship that might make Hibernate try to access a temporary table that does not exist yet.
// JDBC CREATE TEMPORARY TABLE foobar (...);
while(hasWork == true) {
myObj = Session.get(Foobar.class, new Long(1));
// Do work
Session.saveOrUpdate(myObj);
}
Session.flush();
// JDBC DROP TEMPORARY TABLE foobar;
// or force a session reset/close of the underlying JDBC connection, so its not
// returned to the connection pool with the TEMPORARY table still in existance for
// the next user to see.
If you want fully dynamic temporary with table names known at runtime and data types / column names all dynamic, I think you are out of luck, due to SessionFactory startup overheads.