[hibernate-dev] hibernate-extras

[Steve Ebersole]

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