将虚拟 guid 与 ServiceStack 的 OrmLite 结合使用，某些字段填充空 guid 而不是值。可能是什么原因造成的？

Question

具体来说，我正在尝试检索具有"00010600-0000-0000-0000-0000000000000"值作为类中的 Id 的行。

我尝试使用 ado 来检索要检查的列，它适当地返回值，但是当我尝试使用 Select（） 或 GetByIdOrDefault（id） 时，我的对象返回时，除了 Id 字段作为空 guid 返回。

Id 列设置为表的主键。

编辑：

[Test]
public void Test() {
    var dbFactory = new OrmLiteConnectionFactory(_configuration.ConnectionString);
    using (var conn = dbFactory.OpenDbConnection()) {
        var nodes = conn.Select<TreeNode>();
        foreach (var node in nodes) {
            Console.WriteLine(node.Id);
        }
    }
}

此测试复制了我遇到的问题。我遇到问题的一些 Guid 是：

00010600-0000-0000-0000-000000000000
00010100-0000-0000-0000-000000000000
00000300-0000-0000-0000-0000000000000

Answer 1

问题与作为对象中的枚举的字段有关，并且该字段的值使用空格设置不正确，无法映射回枚举。这导致该行的所有其他映射失败。

public static T PopulateWithSqlReader<T>(this T objWithProperties, IDataReader dataReader, FieldDefinition[] fieldDefs, Dictionary<string, int> indexCache)
{
    try
    {
        foreach (var fieldDef in fieldDefs)
        {
            int index;
            if (indexCache != null)
            {
                if (!indexCache.TryGetValue(fieldDef.Name, out index))
                {
                    index = dataReader.GetColumnIndex(fieldDef.FieldName);
                    if (index == NotFound)
                    {
                        index = TryGuessColumnIndex(fieldDef.FieldName, dataReader);
                    }
                    indexCache.Add(fieldDef.Name, index);
                }
            }
            else
            {
                index = dataReader.GetColumnIndex(fieldDef.FieldName);
                if (index == NotFound)
                {
                    index = TryGuessColumnIndex(fieldDef.FieldName, dataReader);
                }
            }
            if (index == NotFound) continue;
            var value = dataReader.GetValue(index);
            fieldDef.SetValue(objWithProperties, value);
        }
    }
    catch (Exception ex)
    {
        Log.Error(ex);
    } 
    return objWithProperties;
}

上述方法中的 try/catch 吞噬了这个问题，除非打开日志记录（应该是，我的错），否则这个问题不会被注意到。