RE: [hibernate-dev] hibernate-extras
I stand with Michael about introduction of a hibernate-extra jar-file. I use the DB2400 and 390 dialect a lot and we have had a hard time getting our mainframe sysadmins to allow Hibernate on their precious mainframe. Physically removing these crucial parts to another jar file labelled as "unmaintained and untested" will not help gain their trust. Is there no other way to get this messages out there without creating another jar-file? Perhaps a list on the Hibernate website? This will also be more flexible in ways of changing the status of "unmaintained and untested" parts. Just my two cents as do understand the difficulties you are facing in maintaining these parts. Kind regards, Peter -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Michael Plöd Verzonden: maandag 12 november 2007 23:29 CC: hibernate-dev@lists.jboss.org Onderwerp: Re: [hibernate-dev] hibernate-extras Sorry for the last message I need to get used to my iPhone :-( I totally see your point but judging from my experience the WS customer is an extremely conservative one that wants everything to be "supported" within the "1st class" Jar file. I know this is hillarious but that's the way I saw some WS customers act. I know about one of my customers that will really discuss this. Am 12.11.2007 um 23:14 schrieb Steve Ebersole <[EMAIL PROTECTED]>: > On Monday 12 November 2007 04:04:22 pm Michael Plöd wrote: >> Honestly I think that the WebSphere TransactionManager Lookups should >> remain in the "core" bundle. I know that it is a pain to test and >> maintain but I think that Hibernate is Quote popular in WS >> environments > Funny, the WS TM lookups are, to me, the epitome of what should get > moved ;) > And the point is not that "it is a pain to test and maintain"; the > point is > that it is not tested and is not maintained on a consistent basis, > or at all. > > Do you really think having the classes in one jar or another will > make them > any less popular or usable? > > IMO, the thing that is being missed here is the ideal of open- > source, which is > that someone with a stake in these WS TM lookups steps up and > maintains it. > >> Cheers, >> Mike >> >> Am 12.11.2007 um 22:41 schrieb Steve Ebersole <[EMAIL PROTECTED]>: >>> Starting with 3.3 I plan on introducing hibernate-extras, which will >>> be a >>> separate jar which will include code which is un-tested and un- >>> maintained by >>> committers. The impetus for this move is simply to make it clear to >>> users >>> what pieces of functionality are tested in an ongoing fashion and >>> are >>> maintained by the Hibernate committers, versus those which are not. >>> >>> Users should have certain expectations in regards to those which are >>> not >>> (the "extras"). One such expectation is the fact that the quality >>> may or may >>> not be on par with the rest of the codebase; the important point >>> being that >>> we cannot guarentee the quality. Another expectation would be in >>> regards to >>> support for that functionality, and the fact that for whatever >>> reason noone >>> with expertise on those components owns its maintenance; thus >>> improvements >>> and bug-fixes would be expected to be patches from the community (or >>> that >>> someone with a stake in that functionality would stand up and take >>> on its >>> maintenance). >>> >>> The code I currently see being moved there is quite a few of the >>> TransactionManagerLookup impls and some of the Dialects (non- >>> exhaustive): >>> org.hibernate.dialect.DB2390Dialect >>> org.hibernate.dialect.DB2400Dialect >>> org.hibernate.dialect.FirebirdDialect >>> org.hibernate.dialect.FrontBaseDialect >>> org.hibernate.dialect.InformixDialect >>> org.hibernate.dialect.JDataStoreDialect >>> org.hibernate.dialect.MckoiDialect >>> org.hibernate.dialect.MimerSQLDialect >>> org.hibernate.dialect.PointbaseDialect >>> org.hibernate.dialect.ProgressDialect >>> org.hibernate.dialect.RDMSOS2200Dialect >>> org.hibernate.dialect.SAPDBDialect >>> org.hibernate.transaction.BESTransactionManagerLookup >>> org.hibernate.transaction.JOnASTransactionManagerLookup >>> org.hibernate.transaction.JOTMTransactionManagerLookup >>> org.hibernate.transaction.JRun4TransactionManagerLookup >>> org.hibernate.transaction.OC4JTransactionManagerLookup >>> org.hibernate.transaction.OrionTransactionManagerLookup >>> org.hibernate.transaction.WebSphereExtendedJTATransactionLookup >>> org.hibernate.transaction.WebSphereTransactionManagerLookup >>> >>> (this is in addition to the already done splits on trunk) >>> >>> Anyone feel any of the above should remain in the core bundle? >>> Anything else >>> we should move? >>> >>> >>> -- >>> 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 >>>
Re: [hibernate-dev] hibernate-extras
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
Re: [hibernate-dev] hibernate-extras
On Tuesday 13 November 2007 06:19:46 am Schuler, Peter wrote: > I stand with Michael about introduction of a hibernate-extra jar-file. > > I use the DB2400 and 390 dialect a lot and we have had a hard time getting > our mainframe sysadmins to allow Hibernate on their precious mainframe. > Physically removing these crucial parts to another jar file labelled as > "unmaintained and untested" will not help gain their trust. > > Is there no other way to get this messages out there without creating > another jar-file? Perhaps a list on the Hibernate website? This will also > be more flexible in ways of changing the status of "unmaintained and > untested" parts. > > Just my two cents as do understand the difficulties you are facing in > maintaining these parts. > > Kind regards, > Peter > Simply listing them on a website page does not have nearly the effect moving them to another jar has. In terms of dialects, this is already the case and in fact has been for over 2 years. And yet, it takes the mere suggestion of removal to a seperate jar to get any type of reponse. Honestly, what I really want is some ownership. Trust me, I'd rather not separate these; I'd much rather have individuals take responsiblity for maintaining each of these pieces. -- 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
Re: [hibernate-dev] hibernate-extras
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. My main issue with database connections for configration and sessionfactory building is: 1) The database might not be needed at all (e.g. for pure codegeneration from the metadata) 2) The database might not be running at all when doing development (related to 1) 3) It can be *really* slow to create connections and read metadata (gives bad user experience in an ui) 4) Not all users have access rights to read this metadata information So iff this gets added to the dialect then I would say the following should be true: 1) There should be an option/flag for not giving the dialects the option to spend time getting the metadata 2) Since the dialects might not get the connection or the user does not have proper rights to inspect the metadata they should have sensible defaults anyway - or even be able to get the base information like major/minor version from other settings etc. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
