Hi Oskar, thanks for taking the time and looking at this. I created the first 2 Issues in Jira (https://nhibernate.jira.com/browse/NH-3586 and https://nhibernate.jira.com/browse/NH-3587). The second issue is unfortunatly still not solved so I'll wait with the pull request.
You can find my current work here: https://github.com/amroel/nhibernate-core/tree/fix_firebird with the list of current changes: https://github.com/amroel/nhibernate-core/compare/fix_firebird The changes includes the refactoring for the third Issue which is now working for both Firebird and MS-SQL. I have'nt tested it for other dialects but it should be working. The failing tests dropped from 500+x down to 54, but there is still a lot of work to do. On Wednesday, January 8, 2014 7:21:31 AM UTC+1, Oskar Berggren wrote: > > > > > 2013/12/23 Amro El-Fakharany <[email protected] <javascript:>> > >> Hi Everybody, >> I noticed that there are some (actually a lot!) tests broken for Firebird >> and I decided to tackle each Problem one by one. >> > > Excellent! > > > >> >> So far I have found three Issues wich are (roughly description): >> 1) Decimal data type: Firebird does'nt support precisions larger than 18 >> and the default of nh is 19. >> I extended the FirebirdDialect to override the "GetTypeName" method and >> swap larger Decimal precisions with 18. >> >> 2) Parameters Within a select clause: Firebird needs a typecast if a >> parameter is used within a select clause. >> I extended the FirebirdClientDriver to override the AdjustCommand method >> and typecast the parameter. >> > > > Please open separate issues in Jira and submit pull requests for this. > > > > > >> 3) Temporary Tables: Firebird supports temporary Tables, which must be >> created in an isolated transaction, and so I thought it is just a matter of >> extending the dialect and overriding the related properties and methods. >> > > I read somewhere that Firebird supports transactional DDL - does it not > include temporary tables in this? > > > As for the below, the code in *TmpIdTableCreationIsolatedWork* was added > in 2009 and appears to only be used in fairly limited scenarios, so it's > not inconceivable that there are still bugs in it. It certainly looks a bit > strange. You might have a look at the corresponding java code in Hibernate > to see how that looks. > > [...] > > return result; >> >> Now I think the solution is actually simple, namly refactor the >> TmpIdTableCreationIsolatedWork.DoWork to use the passed in parameters, but >> I need to make sure that other dialects will not be affected. >> (After all there must be a reason why the original author(s) ignored the >> passed in parameters right?) >> >> 1) Does any dialect support DDL statements within the same transaction as >> the one which actually usese them (such as selects or inserts) at all? >> > > Yes, Postgresql has a very robust implementation of mixing DDL and DML > inside the same transaction. SQL Server too can handle many things, as can > several other RDBMS. > > > >> 2) If yes, will they be broken if we did the refactoring or do they also >> support DDL in separate transactions? >> > > Whatever refactoring is made, for the databases where the current behavior > is correct, that behavior should remain. (even if the current connection > happens to be accessed using a different parameter.) > > > >> 3) Can we remove the *if >> (Factory.Settings.IsDataDefinitionInTransactionSupported) *and instead >> just stick with *Isolater.DoIsolatedWork(work, session);*? >> > > I haven't analyzed this. > > > /Oskar > > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
