Ok but we have to "touch" our tests. When a NH feature is not supported by a DataProvider/RDBMS we have to ignore a test for that specific dialect.
On Tue, Jul 27, 2010 at 10:42 AM, Stephen Bohlen <[email protected]> wrote: > I've a local VM with the following DBs installed for general testing > purposes for other db-related OSS projects: > > - MS SqlServer 2005 + 2008 > - OracleXE 11g (behaves identically to ORA Enterprise in re: > db-specific feature support) > - MySQL 5.x > > It would be easy for me to perform the dialect tests against these > platforms (and probably also easy to add PostGres, Firebird, DB2, etc. > installs to the VM as well to cover a wider array of supported dialect > targets). > > No point in my centralizing all of this infrastructure myself though if it > duplicates what we already have handy access to -- which dialects are > presently not consistently run as part of our test-scope(s)? Sounds > (unsurprisingly) like we're covered on MS SQL Server, but which of the > others remain inconsistently tested and need to be exercised --? > > Steve Bohlen > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > > > > On Tue, Jul 27, 2010 at 9:22 AM, Fabio Maulo <[email protected]> wrote: > >> We do that for NH2.0 and NH2.1 >> I toke FireBird and ORACLE (as you can see in SVN log ;) ) >> I don't remember who toke MySQL, PostGre and some others... >> >> >> On Tue, Jul 27, 2010 at 10:05 AM, John Davidson <[email protected]>wrote: >> >>> Is there any way to get a more formal approach to database dialect >>> testing accomplished, rather than trying to do it by memory and >>> paper-analysis. Would it be possible to identify individuals to volunteer >>> for a testing a dialect, especially prior to a GA release, and then if not >>> all dialects are covered to solicit assistance from the nhusers for those >>> untested dialects? >>> >>> John Davidson >>> >> >> >> >> -- >> Fabio Maulo >> >> > -- Fabio Maulo
