我正在使用Fluent NHibernate自动化,并使用以下代码来确保NHibernate不会消除毫秒:
public class TimestampTypeConvention : IPropertyConvention, IPropertyConventionAcceptance
{
public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)
{
criteria.Expect(x => x.Type == typeof(DateTime) || x.Type == typeof(DateTimeOffset));
}
public void Apply(IPropertyInstance instance)
{
instance.CustomType<TimestampType>();
}
}
这非常有效,因此数据可以正确存储在数据库中。
但是,当我运行以下LINQ查询时,我没有得到我期望的匹配:
bool isDuplicate = session.Query<TagData>()
.Any(x => x.TagName == message.EventTag.TagName
&& x.TimeStamp == message.EventTag.TimeStamp.UtcDateTime);
生成的SQL看起来像这样,并解释了为什么这不起作用:
select tagdata0_."Id" as column1_0_, tagdata0_."TagName" as column2_0_,
tagdata0_."TimeStamp" as column3_0_, tagdata0_."Value" as column4_0_,
tagdata0_."QualityTimeStamp" as column5_0_, tagdata0_."QualitySubstatus" as column6_0_,
tagdata0_."QualityExtendedSubstatus" as column7_0_, tagdata0_."QualityLimit" as column8_0_,
tagdata0_."QualityDataSourceError" as column9_0_, tagdata0_."QualityTagStatus" as column10_0_,
tagdata0_."TagType" as column11_0_ from "TagData" tagdata0_
where tagdata0_."TagName"=:p0 and tagdata0_."TimeStamp"=:p1 limit 1;
:p0 = 'VALVE_HW_CMD' [Type: String (0)],
:p1 = 01.03.2013 16:51:30 [Type: DateTime (0)]
如何强制生成的查询使用完整精度?
BTW,message.EventTag.TimeStamp
是DateTimeOffset
答案 0 :(得分:0)
我被日志记录输出所迷惑:实际的SQL(取自PostgreSQL日志文件)如下所示:
SELECT this_."Id" as column1_0_0_, this_."TagName" as column2_0_0_,
this_."TimeStamp" as column3_0_0_, this_."Value" as column4_0_0_,
this_."QualityTimeStamp" as column5_0_0_, this_."QualitySubstatus" as column6_0_0_,
this_."QualityExtendedSubstatus" as column7_0_0_, this_."QualityLimit" as column8_0_0_,
this_."QualityDataSourceError" as column9_0_0_, this_."QualityTagStatus" as column10_0_0_,
this_."TagType" as column11_0_0_ FROM "TagData" this_
WHERE this_."TimeStamp" = ((E'2013-03-01 16:51:30.509498')::timestamp)
这就是它没有按预期工作的真正原因:PostgreSQL中的timestamp
列只有微秒精度,而DateTimeDiff
这里的值为16:51:30.5094984,其中意味着1/10微秒精度。保持完整准确性的唯一方法似乎是将滴答存储在数据库中。
(我混淆的另一个原因是我在不同的线程上或多或少同时收到了来自MassTransit的重复消息,因此检查数据库中的重复项当然并不总是有效.O,多线程的奇迹!)