As a naming note, the existing TimeAsTimeSpanType has the system type
on the right side of the As.
Be aware also that the "time" column type in SQL only holds the time
of day (24h). There is no proper interval type in SQL Server, so I
would argue that Int64 is the preferred storage mechanism for
TimeSpans.
I think the types you're talking about are actually:
TimeType
TimeAsTimeSpan
TimeSpanType
I don't understand why you'd need to introduce any new types.
Patrick Earl
On Sun, Apr 24, 2011 at 3:06 PM, Fabio Maulo <[email protected]> wrote:
> That change, in the driver, is not enough
> I'll introduce two new NH's types.
> - DateTimeToTimeSpanType (Maps a System.DateTime Property to an
> System.TimeSpan column which type is DbType.Time).
> - TimeSpanType (Maps a System.TimeSpan Property to an System.TimeSpan column
> which type is DbType.Time).
> - breaking change for the old one TimeSpanType who will renamed to
> TimeSpanAsInte64Type
> The Sql2008ClientDriver will "only" set the SqlDbType to SqlDbType.Time (I
> have found another bug in that DataProvider, when you set only the DbType of
> the parameter to DbType.Time, if you read it, it is DbType.DateTime).
> Workaround fabric on the road....
> On Sat, Apr 23, 2011 at 7:31 AM, Fabio Maulo <[email protected]> wrote:
>>
>> the default driver per dialect is there since long time... the matter
>> is that there was various bugs... I think that few days ago I have
>> fixed the last.
>>
>> --
>> Fabio Maulo
>>
>>
>> El 23/04/2011, a las 07:00, "Richard Brown \(gmail\)"
>> <[email protected]> escribió:
>>
>> > The Dialect having a default Driver makes sense to me (and is nice - one
>> > less thing to configure).
>> >
>> >
>> > -----Original Message----- From: Patrick Earl
>> > Sent: Saturday, April 23, 2011 5:42 AM
>> > To: [email protected]
>> > Subject: Re: [nhibernate-development] end of just one SqlClientDriver
>> > panacea
>> >
>> > Did you actually mean driver select dialect or other way around?
>> >
>> > On Fri, Apr 22, 2011 at 5:17 PM, Stephen Bohlen <[email protected]>
>> > wrote:
>> >> That makes sense to me (have the driver select the 'best' dialect and
>> >> then
>> >> permit the user to override if they want some 'non-best' behavior).
>> >
>
>
>
> --
> Fabio Maulo
>
>
