NHibernate - Y at-il un quelconque intérêt à définir l'attribut de longueur pour les propriétés/colonnes?

Question

généralement la définition de la propriété/colonne ressemble à ceci:

<property name="DocumentSummary" column="DocumentSummary" length="100" type="String"> 
    <column name="DocumentSummary" /> 
</property> 

Je supposais que NHibernate validera les données en utilisant l'attribut de longueur avant d'insérer/mettre à jour une ligne. Malheureusement, il semble que ce soit une hypothèse invalide. Donc, question est si NHibernate utilise l'attribut de longueur pour quelque chose? Est-il logique de le définir pour chaque propriété?

Answer 1

Il l'utilise pour créer la définition de base de données sql. Regardez la classe SchemaExport.

Answer 2

Vous pouvez également extraire les longueurs des mappages par programme, voir this question. Notez que c'est pour Java Hibernate, mais je crois que vous pourriez être en mesure de traduire cela en NHibernate.

Answer 3

Oui, la définition de la propriété Length est différente lorsque vous avez des colonnes de chaîne dont la longueur dépasse la longueur maximale par défaut.

Nous avons une colonne de type NVARCHAR(MAX). Si nous n'avions pas défini la propriété length, NHibernate ne définirait pas la valeur de chaîne si la valeur avait une longueur supérieure à 4096 caractères.

(Cet exemple utilise la cartographie par-code, parce que nous sommes en 2017 :-)

classMapper.Property(
         tickerFeed => tickerFeed.StaticTickerText, 
         propertyMapper => 
         { 
          propertyMapper.Column("StaticTickerText"); 
          propertyMapper.Length(int.MaxValue); 
         } 
        ); 

Cependant, nous avons constaté que nous pouvions obtenir le même résultat en utilisant IPropertyMapper.Type de stipuler qu'il était une grande chaîne .

classMapper.Property(
         tickerFeed => tickerFeed.StaticTickerText, 
         propertyMapper => 
         { 
          propertyMapper.Column("StaticTickerText"); 
          propertyMapper.Type(NHibernateUtil.StringClob); 
         } 
        ); 

Nous avons fini par aller avec l'option propertyMapper.Type, car il est plus explicite.