I am for considering the SQL Server DbType.DateTime type to be deprecated starting from 2008 dialect. So it should be transparently replaced by DbType.DateTime2 by those dialects when user specify any NHibernate DateTime type. The NHibernate type DateTime2 is so vendor specific that it should not exist. I think it should be obsoleted in favor of the Timestamp type. Adding a "high precision" type looks redundant with timestamp, or am I missing something?
Now we have the local, utc and db variants. They need to be made available for both datetime "milliseconds ignored" (already there) and timestamp (utc recently added, local and db still missing). Preferably with a coherent naming. (We have UtcDateTime and TimespanUtc: we should choose whether to put it as a prefix or suffix, and do the same on datetime and timespan, for utc and local, maybe db too. Or eventually support both prefix and suffix for all ^^.) Of course we will need to make sure it will be supported by the probably numerous cases where the db tables continue using the deprecated SQL Server DateTime while NHibernate will, with 2008 dialects and upper, use DbType.DateTime2 to map them. Le mardi 25 avril 2017 23:43:51 UTC+2, Alexander Zaytsev a écrit : > > Any ideas on the design for this improvement? > > ---------- Forwarded message ---------- > From: Oskar Berggren (JIRA) > Date: Mon, Nov 14, 2016 at 5:24 AM > Subject: [JIRA] (NH-3919) Clean up and harmonize datetime types with > regards to different dialects > > > Oskar Berggren > <https://nhibernate.jira.com/secure/ViewProfile.jspa?name=oskar.berggren> > *updated* an issue > > NHibernate <https://nhibernate.jira.com/browse/NH> / [image: Improvement] > <https://nhibernate.jira.com/browse/NH-3919> NH-3919 > <https://nhibernate.jira.com/browse/NH-3919> > Clean up and harmonize datetime types with regards to different dialects > <https://nhibernate.jira.com/browse/NH-3919> > Change By: Oskar Berggren > <https://nhibernate.jira.com/secure/ViewProfile.jspa?name=oskar.berggren> > 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 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. > [image: Add Comment] > <https://nhibernate.jira.com/browse/NH-3919#add-comment> Add Comment > <https://nhibernate.jira.com/browse/NH-3919#add-comment> > > This message was sent by Atlassian JIRA (v1000.526.2#100018-sha1:d415428) > [image: Atlassian logo] > > > > > -- --- 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/d/optout.
