I reckon those fixes are possible ... personally, I'd opt for the easy (for
now) option of returning the tests to running only on Oracle, then address
dialects one at a time as time permits.
-----Original Message-----
From: cremor
Sent: Friday, January 13, 2012 1:34 PM
To: nhibernate-development
Subject: [nhibernate-development] Re: NH-2914 and using hour() et.al on
columns where the database type is "date"
Isn't it possible to do the same fixes for other dialects too? I don't
know if the following is correct MSSQL syntax, but wouldn't something
like that work?
RegisterFunction("hour", new SQLFunctionTemplate(NHibernateUtil.Int32,
"datepart(hour, cast(?1 as datetime))"));
I'd assume that casting a DATE to DATETIME in MSSQL would fill the
time parts with 0.
On 13 Jan., 14:09, Oskar Berggren <[email protected]> wrote:
I just committed a fix for NH-2914 from cremor, which implements
support for the hour(), minute() and second() functions in Oracle also
for the DATE type. This also allows use of e.g. datetime.Hour etc. in
LINQ.
Oracle's DATE type apparently can also store time information.
Perhaps in a too hasty move, I suggested that the test cases should be
allowed for all dialects. However the tests now fail on several
dialect, since they don't allow the corresponding SQL features on DATE
columns, since e.g. MSSQL doesn't store time information.
For now, I'll just disable the tests for anything but Oracle again,
since it's most relevant there. However, it got me thinking:
Show we make hour() et.al. simply return 0 if they are used on a
datetime property which is mapped to a sql type that doesn't contain
time information?
/Oskar
