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.
