Re: [hibernate-dev] Contributed with HiRDB Dialect

Dialect "registration" in DialectFactory would be fantastic. It was planned from the get-go, but I never had a chance to circle back around to it. Its not all that difficult. But we should agree on a basic format for the externalized definitions.

Like Chris said, we need to do an "extras" module anyway at some point. So let us know if you'd like this Dialect added there when we do.

- Steve Ebersole Project Lead http://hibernate.org steve(a)hibernate.org Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com steve.ebersole(a)jboss.com steve.ebersole(a)redhat.com On Thu, 2008-09-18 at 19:28 +0900, tomoto.shimizu.vt(a)hitachi.com wrote: > Hi Chris, > > Thank you for the suggestions in this detail. I understand the issues > about maintainance and testing, and it is quite natural that you would > like to be going to put those codes that you could not completely take > care of aside from the core code. > > I think I could go for option 3 as you suggested (perhaps shipping via > a download site), and it would be great enough if users could see the > link to the site on hibernate.org. So I or someone else in my > organization will let you know the URL of the download site when we > have successfully made it ready. (It might not be very soon, though.) > I will discuss with HiRDB team on it. > > Thank you again for taking your precious time to look into my proposal > and give me suggestions. When I did something useful more in common > next time (say, registering an entry to DialectFactory from outside), > I would like to contribute again. > > Tomoto > > P.S. > Please call me just Tomoto. I have some experiences in working with > non-Japanese so I am totally comfortable with being called by first > name without -san. > > > >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: > >> Hi Chris, > >> > >> Unfortunately, there is no free version of HiRDB. I think I could do > >> (a) running the tests in our side and sending you the result or > >> (b) getting a copy for you from my organization (perhaps arranging some > >> kind of contract would be required but I'm not sure). Which do you want > >> me to do? > >> > >> I guess (a) is easier for both of us if you don't have to keep HiRDB > >> with you for regular testing. I already have the test result on 3.2.5. > >> If you would like me to test on another version, I could do it also. > >> > >> Thanks, > >> Tomoto > >> > >> > >> On Fri, 05 Sep 2008 13:35:00 -0400 > >> Chris Bredesen <cbredesen(a)redhat.com&gt; wrote: > >> > >>> 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: > >>>> Hi, my name is Tomoto at Software Division in Hitachi. > >>>> > >>>> I have posted a dialect for HiRDB (Hitachi's RDBMS, see *1) to JIRA. > >>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3465 > >>>> > >>>> I would appreciate it if someone in the team could take a look at it > >>>> for evaluation, and I would be happy to solve the issues you saw if > >>>> any. I really wish this dialect to be incorporated into Hibernate > >>>> so that our customers could easily use Hibernate on HiRDB. > >>>> > >>>> This dialect comes with a feature to allow the user to declare the > >>>> parameter types of user-defined functions in the properies file. It > >>>> was necessary because HiRDB required ? parameters to be qualified by > >>>> 'as <type>' in user-defined function invocations. If there were > >>>> other databases that required the similar feature, and if you thought > >>>> my implementation was good enough to let them use, I might be able to > >>>> make an entry point on the Dialect base class so that other subclasses > >>>> could use it more easily. > >>>> > >>>> *1 http://www.hitachi.co.jp/Prod/comp/soft1/global/prod/hirdb/ > >>>> > >>>> Thank you in advance, > >> > >_______________________________________________ > >hibernate-dev mailing list > &gt;hibernate-dev(a)lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev