I'm glad to hear that I was on the right track. I look forward to the updated dialect.
I wanted to point out one other thing. We are also using the Hibernate Reverse Engineering tool. We came across some issues in Cache involving foreign keys and meta data, in particular the default generated keys weren't unique and there were issues with exported keys being removed in the meta data(Tables B and C have a foreign keys to Table A. Table B get recompiled then exported keys from Table A to Tables B and C might get deleted). This caused the hibernate tool reverse engineering to not work. We were able to get around these issues with some hacks in the code where we repair the meta data, but we wanted to let you know there were issues.
If you want more information, I assume you have my email on file.
I've been meaning to ask the Intersystems people what their thoughts are, after all in some press releases they make a big deal about the hibernate dialect even though it's so old.
I don't think knowing the proper way of doing it is possible without in depth knowledge of both hibernate and cache, something I'm not sure anyone has, but this works for us.
We came across the same issue earlier this year. Our tack was similar though the details differ, in particular which bulkstrategy was used. We just changed the AfterUseAction to Clean and kept the basic strategy. Why did you choose to change the strategy to LocalTemporaryTableBulkIdStrategy.
public class Cache71DialectAltered extends Cache71Dialect { @Override public MultiTableBulkIdStrategy getDefaultMultiTableBulkIdStrategy() { return new GlobalTemporaryTableBulkIdStrategy(new IdTableSupportStandardImpl() { @Override public String generateIdTableName(String baseName) { final String name = super.generateIdTableName(baseName); return name.length() > 25 ? name.substring(1, 25) : name; } @Override public String getCreateIdTableCommand() { return "create global temporary table"; } }, AfterUseAction.CLEAN); } }