Prise en charge de types spécifiques SQL Server pour OrmLite

Je viens d'apprendre à propos d'un type de génie qui simplifierait beaucoup mon travail, mais il semble que mon ORM préféré ne le reconnaisse pas.

Existe-t-il une solution de contournement pour laisser ServiceStack OrmLite reconnaître HierarchyId dans SQL Server? Des suggestions sur les files à modifier et les astuces pour continuer?

MODIFIER :

Voici une meilleure illustration du problème. J'ai la class suivante:

 public class MyClass { public int Id { get; set; } public SqlHierarchyId HierarchyId { get; set; } }

SqlHierarchyId est un type de données SQL Server personnalisé. OrmLite va générer la class suivante pour cela:

Premier rendu MyClass

Assez drôle, je peux utiliser l' [SsortingngLength(255)] sur la propriété et il obtiendra le type de varchar(255) place:

Deuxième rendu MyClass

J'ai manuellement changé la table ici et ajouté le type de données de colonne pour montrer la différence. Veuillez noter le type de données de la troisième colonne:

SqlHierarchyId

Avoir une représentation varchar est parfaitement bien avec d'autres SGBD car il peut être converti en C # , mais avec SQL Server, il est préférable de le faire correspondre au type de données correspondant. Cela facilitera la création de vues (grâce aux fonctions embeddedes du type de données hierarchyid ).

Je sais que le type n'est pas supporté par EF4 (pas sûr de 5). J'ai également parcouru le file OrmLiteDialectProviderBase.cs sur GitHub et je peux voir une list de types de données ADO.NET supportés.

Ma question simple est: Est-ce une limitation forte par ADO.NET ou cela peut être vu dans OrmLite? Je suis disposé à aider à prolonger cette partie si des suggestions sont faites.

ADO.NET prend en charge le type hierarchyid, un exemple peut être trouvé ici et montre ADO.NET peut lire les valeurs de Sql Server directement comme hierarchyid mais vous devez passer des parameters au server sous la forme d'une string.

L'ajout de la prise en charge des methods de type hierarchyid à une structure ORM romprait l'abstraction entre l'API ORM et le RDMS. Je suppose que c'est la raison pour laquelle une telle fonctionnalité n'a pas été ajoutée à Entity Framework.

Vous pouvez contourner le problème en conservant une représentation sous forme de string de la hiérarchie dans votre database et ayant la propriété hierarchyid comme une propriété calculée dans votre database et votre class C #, vous devez exclure la propriété C # calculée du mappage ORM.

Par exemple votre colonne de table serait déclarée comme:

 [SqlHierarchyId] AS ([hierarchyid]::Parse([HierarchyId])) PERSISTED

et votre class comme:

 public class MyClass { public ssortingng HierarchyId { get; set; } [Ignore] public SqlHierarchyId SqlHierarchyId { get { return SqlHierarchyId.Parse(new SqlSsortingng(HierarchyId)); } set { HierarchyId = value.ToSsortingng(); } } }

Cela mettra à jour les mises à jour à partir de la couche .Net et vous permettra d'utiliser les methods hierarchyid pour build des requêtes dans SQL Server et travailler avec des objects matérialisés dans la couche .Net.

Vous auriez à build des requêtes sur la représentation de la string dans votre couche ORM, mais cela pourrait encore tirer parti de certaines des methods d'aide de hierarchyid, par exemple:

 public IEnumerable<MyClass> GetDescendants(MyClass node) { ssortingng currentLocation = node.HierarchyId; ssortingng followingSibling = node.SqlHierarchyId.GetAncestor(1) .GetDescendant(node.SqlHierarchyId, SqlHierarchyId.Null) .ToSsortingng(); return db.Select<MyClass>(n => n.HierarchyId > currentLocation && n.HierarchyId < followingSibling); }

Aplogies si j'ai la syntaxe ORMLite erronée.