Tomoto, Thank you for the contribution! Is there somewhere that one might obtain a copy of HiRDB to run the unit tests against? -Chris tomoto.shimizu.vt(a)hitachi.com wrote:

Tomoto-san, I've had a conversation with Steve regarding the addition of new Dialects such as the one you've proposed. Here are the options: 1. Integrate a new org.hibernate.dialect.HiRDBDialect into Hibernate's source code. This is reasonable for mainstream highly used databases that most users would expect us to provide support for. In this scenario, there's an implied responsibility on behalf of the Hibernate team to ensure that they remain usable as Hibernate and the RDBMS evolves. While it's great to get contributions for new and interesting platforms, sometimes this happens "one time only" and in 5 years, we're left with a Dialect that nobody can use and nobody is available to maintain it. 2. Integrate a new org.hibernate.dialect.HiRDDialect into an optional distribution that users are free to download and use at their leisure. This is a good choice for less used integration pieces that may be less actively maintained than core code. We are open to this for your case but it would take some time to set up (Steve can comment on exactly when this might take place). 3. Ship HiRDBDialect as a download from hitachi.co.jp or part of the HiRDB JDBC distribution (in a com.hitachi.* package). I actually like this option a lot because it is clear who owns/maintains the code. Also, new versions of the Dialect can be shipped as HiRDB evolves and releases new versions. Including it with the JDBC driver would make the Hibernate dialect available automatically to anyone who needs it. What do you think of option 3? Is this something you can facilitate along with the team that maintains the JDBC driver? We will be happy to provide links to the downloadable Dialect on hibernate.org so that users can find things easily. If this is not an option, I'll discuss the creation of an "extras" module that can house code like this. We may have to do this already because there are some existing bits of code that really should not be part of the core distribution for reasons outlined above. There's also the issue of testing. I don't envision acquiring hardware and licenses to HiRDB so that we can make it part of our QA suite. Shipping a Dialect as part of the core distribution tends to give users the impression that we are 100% confident in its quality (even if our web site says differently). We clearly can't be 100% confident in code quality when we don't actively test against a given scenario. Based on this I think option 3 is the best but please let me know if this can work for you. Cheers, Chris Tomoto Shimizu Washio wrote: