It would be good if you could isolate the changes for the first two issues into one commit each, and submit them (and only them) as a pull request on github (referencing the jira issue numbers).
/Oskar 2014/1/9 Amro El-Fakharany <[email protected]> > Hi Alexander, > > I'm afraid I didn't understand you quite right. I did post 2 links to my > fork of the repository and the changes i've made! Did I misunderstood you? > Of course I can make a pull request if it helps more, it's just that I > consider the work done so far to be "in Progress". > > Amro > > > > *Von:* [email protected] [mailto: > [email protected]] *Im Auftrag von *Alexander I. > Zaytsev > *Gesendet:* Donnerstag, 9. Januar 2014 07:38 > *An:* [email protected] > *Betreff:* Re: [nhibernate-development] Firebirds broken tests > > > > Ho Amro, > > > > Can you please share some code or make a pull request? > > > > Best Regards, > > Alexander > > > > 2014/1/9 Amro El-Fakharany <[email protected]> > > 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]> > > > > 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. > > > > -- > > --- > 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. > > -- > > --- > 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. > -- --- 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.
