Changing schema qualifier on generator sequence (bug?)

wontonsoup · **Posted:** Fri Jul 09, 2004 12:50 am

I'm using hibernate 2.1.3 against an Oracle 8i db.

I need to change the schema qualifier for ALL tables and sequences used by hibernate at runtime. All my hibernate.cfg.xml has placeholder value for "default_schema" and none of my mapping files explicitly define the schema (via the schema attribute on the <hibernate-mapping> tag).

I've seen similar postings on this (namely http://forum.hibernate.org/viewtopic.ph ... ass+schema).
In that post, you mention that it's ok to change change the schema name for each PersistentClass (via the Configuration object). The default_schema setting seemed to take care of the tables, but my sequence generators weren't including the schema. I tried 2 different ways of setting the schema for my sequences:

Code:

hibernateConfig.setProperty( "hibernate.default_schema", schemaName ) ;

// method 1
pc.getTable().setSchema( schemaName ) ;

// method 2
hibernateConfiguration.getClassMapping( SomeClass.class ).getIdentifier().getIdentifierGeneratorProperties().setProperty( 
            "sequence", schemaName + ".MY_DB_SEQ" )  ;

Didn't work. So, I linked up the hibernate 2.1.3 source in eclipse and stepped through. Here's the culprit (SimpleValue.createIdentifierGenerator( Dialect ): 81:

Code:

   public IdentifierGenerator createIdentifierGenerator(Dialect dialect) throws MappingException {
      if (uniqueIdentifierGenerator==null) {
         uniqueIdentifierGenerator = IdentifierGeneratorFactory.create(
            identifierGeneratorStrategy, type, identifierGeneratorProperties, dialect
         );
      }
      return uniqueIdentifierGenerator;
   }

When I initially loaded my Configuration from the mapping files on disk, it apparently set up and cached the uniqueIdenfierGenerator (without my schema name prepended to the sequence!!) When I change the SimpleValue using the code above and re-created a new SessionFactory, the cached uniqueIdentifierGenerator remains and my changes are ignored.

Any way this can be fixed? I supposed I can inject the schema attribute into every xml mapping file at runtime using DOM, but that seems like a hack when you guys put together such a nice Configuration interface =(

wontonsoup · **Posted:** Fri Jul 09, 2004 3:33 pm

I "patched" my local version of hibernate by removing the caching of the uniqueIdentifierGenerator. Works fine...nothing seemed to break.

Code:

public IdentifierGenerator createIdentifierGenerator(Dialect dialect) throws MappingException {
   uniqueIdentifierGenerator = IdentifierGeneratorFactory.create(
      identifierGeneratorStrategy, type, identifierGeneratorProperties, dialect
      );

   return uniqueIdentifierGenerator;
}

Is setting up the uniqueIdenifierGenerator expensive? Does it need to be cached? If so, you should mention that some changes made to the Configuration after initialization (like changing generators) will not be manifested in subsequent SessionFactories built by that Configuration.

emmanuel · **Posted:** Mon Jul 12, 2004 1:20 pm

Not sure it will stay unique this way

wontonsoup · **Posted:** Wed Jul 14, 2004 10:04 pm

Quote:

Not sure it will stay unique this way

lol. good call. well, in my case, it will stay unique since all the configuration modification is happening at application startup (i.e. before the sequence is utilized). But, you're right... if I swapped the sequence generator after it had been used, you could get duplicate id's.

So, I guess there's no clean way to programmatically change this value at runtime (via the Configuration API). I suppose I could parse hibernate.cfg.xml, use it to locate all mapping files, run a regex against all of them to replace the schema qualifer on the sequences, re-save (overwrite) all the xml files and THEN load the hibernate Configuration!? Guess I'll just stick with my "patch" for now.

Thanks for your insight Emmanuel.

wontonsoup · **Posted:** Wed Jul 14, 2004 10:09 pm

btw, gavin is way smart for thinking about all this stuff. I wouldn't have thought about caching the sequence generator object, but it makes perfect sense now. It's little things like this that make Hiberate a superior product (compared to most open source endeavours). Props to the Hibernate team