"does no more cut milliseconds." For correctness, I think this should say "does no longer cut fractional seconds" in the official release notes, as the term millisecond is a bit imprecise, and fractional is the term used in SQL standard etc
After all, a time such as 14:35:19.45 does not mean 45 milliseconds but 45/100 fractions of a second. Other than that, fantasic work to get this fixed!!! :) /Oskar ---------- Forwarded message ---------- From: Frédéric Delaporte (JIRA) <j...@nhibernate.jira.com> Date: 2017-10-04 15:22 GMT+01:00 Subject: [JIRA] (NH-3919) Clean up and harmonize datetime types with regards to different dialects To: oskar.bergg...@gmail.com [ https://nhibernate.jira.com/browse/NH-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frédéric Delaporte resolved NH-3919. Assignee: Frédéric Delaporte Fix Version/s: (was: 5.1.0) 5.0.0 Resolution: Fixed Possible breaking changes: - NHibernate type DateTimeType, which is the default for a .Net DateTime, does no more cut milliseconds. Use DateTimeNoMsType if you wish to have milliseconds cut. It applies to its Local/Utc counterparts too. - LocalDateTimeType and UtcDateTimeType do no more accept being set with value having a non-matching kind, they throw instead. - DbTimestamp will now round the retrieved value according to Dialect.TimestampResolutionInTicks. - When an object typed property is mapped to a NHibernate timestamp, setting an invalid object in the property will now throw at flush instead of replacing it with DateTime.Now. - SQL Server 2008+ dialects now use datetime2 instead of datetime for all date time types, including timestamp. This can be reverted with sql_types.keep_datetime setting. - SQL Server 2008+ timestamp resolution is now 100ns in accordance with datetime2 capabilities, down from 10ms previously. This can be reverted with sql_types.keep_datetime setting. - Oracle 9g+ dialects now use timestamp(7) for all date time types, instead of timestamp(4). - Oracle 9g+ timestamp resolution is now 100ns in accordance with timestamp(7) capabilities, down from 100µs previously. - String parameter length will no more be specified by the OdbcDriver. - IMapping interface has an additional Dialect member. ISessionFactoryImplementor has lost it, since it gains it back through IMapping. - IDriver.ExpandQueryParameters and DriverBase.CloneParameter take an additional argument. Clean up and harmonize datetime types with regards to different dialects Key: NH-3919 URL: https://nhibernate.jira.com/browse/NH-3919 Project: NHibernate Issue Type: Improvement Components: Core, DataProviders / Dialects Affects Versions: 3.0.0.GA Reporter: Oskar Berggren Assignee: Frédéric Delaporte Priority: Major Fix For: 5.0.0 Currently, NHibernate's handling of datetime types have some issues: The old DateTimeType maps to SQL datetime on MS SQL server. But since 2008 MS suggests to use the datetime2 type for new development. Support for MS SQL Server's datetime2 SQL type was added using the DateTime2Type, but this is based on using DbType.DateTime2, which is only supported by MSSQL2008Dialect and later, not by other dialects. Unlike the DateTimeType, DateTime2Type also doesn't round to whole seconds. Which is good or bad depending on what you want. There is also LocalDateTimeType and UtcDateTimeType, but no correspondence for DateTime2. There is also TimestampType, which cannot currently be used with SQL Server's datetime2, but since it's intended for versioning it really could benefit from the increased precision. (Actually, it may work with datetime2(3) on SQL Server 2014 and previous, but not on 2016+ because of different rounding behavior when comparing datetime and datetime2 values. We probably want to change the sql server dialect (2008+) to use datetime2 for DbType.DateTime by default. This corresponds to how Hibernate already does it. Then DateTimeType would automatically use datetime2 where available. Probably means modifying the SqlClient2008Driver so that DbType.DateTime gets overriden with DbType.DateTime2 where needed. Then the remaining difference between DateTimeType and DateTime2Type would be that the former rounds to whole seconds, while the latter only works were DbType.DateTime2 is understood. So better to rewrite DateTime2Type to also use DbType.DateTime but without the rounding and call it DateTimeHighPrecisionType or something. — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100063) -- --- 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 nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
