È possibile mapparli come string
o AnsiString
.
<property name="MyBigUnicodeColumn" type="string" length="1000000"/>
<property name="MyBigAnsiColumn" type="AnsiString" length="1000000" />
Ogni volta che la lunghezza è più grande quindi 4000 o 8000, rispettivamente, NH crea un nvarchar (max) o varchar (max).
È possibile che la lunghezza sia utilizzata per i parametri sql e che sia troncata alla lunghezza specificata (dipende dalla versione NH in uso, alcune modifiche sono state apportate). Quindi meglio specificarlo abbastanza grande.
Edit: Purtroppo, non funziona con la AnsiString lo stesso con stringhe normali. Ho letto alcuni codici NH e ho trovato quanto segue:
varchar (max) è supportato dal dialetto da SQL Server 2005 in poi.
MsSql2000Dialect.cs, linea 205
RegisterColumnType(DbType.AnsiString, SqlClientDriver.MaxSizeForLengthLimitedAnsiString, "VARCHAR($l)");
MsSql2005Dialect.cs, linea 19:
RegisterColumnType(DbType.AnsiString, SqlClientDriver.MaxSizeForAnsiClob, "VARCHAR(MAX)");
Registra varchar (max) come il tipo SQL di scegliere quando un AnsiString viene mappato grande poi 8000.
In SqlClientDriver.cs è possibile vedere che implementa "blob" nei parametri per le stringhe, ma non per le stringhe ansi (riga 135):
case DbType.AnsiString:
case DbType.AnsiStringFixedLength:
dbParam.Size = MaxSizeForLengthLimitedAnsiString;
break;
// later on
case DbType.String:
case DbType.StringFixedLength:
dbParam.Size = IsText(dbParam, sqlType) ? MaxSizeForClob : MaxSizeForLengthLimitedString;
break;
Imposta sempre 8000 come limite del parametro di tipo AnsiString.
A causa dell'incongruenza tra il driver e il dialetto, lo chiamerei un bug.
Poiché l'errore si verifica su tutte le AnsiStrings, non aiuta a specificare il tipo sql nel mapping (NH è in grado di scegliere il tipo sql corretto).È necessario utilizzare la soluzione proposta nel thread you started on the NH forum:
<property name="MyBigAnsiColumn" type="StringClob" sql-type="VARCHAR(max)" />
ho segnalato come un bug: https://nhibernate.jira.com/browse/NH-3252
AnsiString è per definizione una stringa non Unicode, quindi questo non dovrebbe essere rotto. Penso che questo cambierebbe solo se i futuri SQL Server offrissero nuovi modi per memorizzare una stringa o una stringa ansi nella lunghezza specificata. –
Dall'altro lato, tutto questo è implementato nel Dialetto, ed è abbastanza facile avere il proprio dialetto. –
Dipende dalla versione NH in uso. Specificano la lunghezza durante il passaggio dei parametri, in modo che SQL Server riutilizzi le query. Il client SQL Server utilizzato per tagliare i dati, che era molto cattivo, quindi il controllo della lunghezza. Se vuoi usare il foro di 2 GB di lunghezza massima, specificalo in questo modo ... –