On Monday 12 November 2007 09:28:12 pm Diego Pires Plentz wrote: > Btw, talking on dialects, I've started to talk with Postgre developers > > http://opensource.atlassian.com/projects/hibernate/browse/HHH-2942 > > They asked for a way to dynamically add functions to the dialect, > doing some query's on db metadata. Another thing is to send database > minor version to DialectFactory, since in Postgre 8.2, major version > is 8 and minor version is 2. I think we could improve it a lot with > their help. > > http://archives.postgresql.org/pgsql-hackers/2007-11/threads.php#00462 >
I'm not a member of that list, so I'll respond here ;) First, the original and current conceptualization of Dialect is a static representation of how to talk to a given database through a given JDBC driver, such that one does not need access to the underlying database in order to use said Dialect. As such, the intention was always that a different way to talk to a database would mean a new Dialect as we see in the various Oracle and MySQL Dialects for versions, etc. And lets not forget that Dialect is in fact an extension point; it is always possible to supply one's own Dialect impl for Hibernate to use. That all being said, I am not immediately against allowing the Dialects to alter or configure themselves based on the JDBC metadata. In fact I had a discussion about this on IRC with Mark Matthews from the MySQL team. We all agree the MySQL Dialects are getting inanely out of hand. That is largely MySQL-specific because of the "cross product" between version and engine. And I think even towards the end of that thread, the pgsql folks started to realize that its probably better (outside this question of "modules") to simply have "static" dialects. but for the sake of argument, lets consider changes... WRT functions, we need to keep in mind that the "return type" we are talking about here is the *Hibernate type*; which are far more varied than the JDBC types. It is probably safe to dynamically map this for database functions, but we should avoid doing this for user-defined functions. Also, regarding a particular comment I saw, the functions only technically need to be registered if their return is being used in a select list (because we'd need to know how to extract the values from the ResultSet); but its generally a good idea to map all of them. If we are changing the contract of Dialect to pass in the metadata (or a connection for it to access the metadata), then I don't see a benefit to passing the minor (nor major either for that fact) version into the DialectFactory. Also, how do we jive this with Max's need to build a SessionFactory which does not have access to the underlying database for tools usage? Max, this would depend on how you use these SessionFactories, and the Dialect associated with it. WRT LOB support, Dialect#supportsExpectedLobUsagePattern is "informational". We use it from the test suite to know to skip certain tests against said Dialect because we know that database has issues with LOB handling. Also, it is meant as informational for the user as well. It's been a while since I've played with the pgsql test suite, so I forget the details, but a search for Dialect#supportsExpectedLobUsagePattern usage within the test suite will show where to start looking. The org.hibernate.test.lob package is the main piece of LOB support testing, although there are other tests that test LOB support as a side effect. The main thing I remember (largely due to javadoc comments on supportsExpectedLobUsagePattern) is actually the creational usage. Someone also mentioned about Dialect#useInputStreamToInsertBlob; that controls whether we use PreparedStatement#setClob/setBlob versus PreparedStatement#setBinaryStream when binding LOB values (see org.hibernate.type.BlobType and org.hibernate.type.ClobType). So, if Dialect#useInputStreamToInsertBlob is incorrect, then that would in fact cause problems with the "expected usage pattern" from a creational perspective ;) And as for the person who claims I did not consider a database might have a version like 8.3, really what I *did consider* was that a major version (i.e. new feature set) would in fact be cause for a major version number increment. Potato/potato ;) But later commenters on that thread point this out as well... -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
