Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Throw exception instead of silently truncate string and blob data

Description

(Preamble: I know there is already a couple of jira issues, blog posts and discussions around. There are some solutions around, but they don't seem to be straight forward to me. There is the statement that it is not NH's error, but IMO NH could do something to fix it. I admit that I don't understand the root of the problem.)

NH seems to truncate strings and blob (byte arrays and serialized objects) silently to the length specified in the mapping file. This became a breaking change (at least in our project), serialized objects can't be deserialized anymore. (Before NH 3.0.0, it just sent it to the database. In case of Sql Server, it either stored it in the nvarchar(max) column which worked well or complained instead of truncating it.)

Truncating serialized data destroys data. It is completely useless to store a truncated serialized object. NH can't decide if the data can be safely truncated (like many text strings) or not.

IMHO, NH should complain (= throw an exception) when the text or byte array is too long. This is a breaking change too. But hold on - currently it is silently destroying data at least in certain cases which is not better then getting an exception thrown when trying to store such data.

Limiting the fields to the length specified in the mapping file would be a database independent behavior. It is never possible to store longer data then specified, regardless if it would be possible by the underlying DBMS (which may use nvarcher(max) for instance). In return we get the assurance that it works on every DBMS reliably.

AFAIK, There is also the complain that blob fields are limited to 4000 by default. This improvement request does not propose any changes in that.

Another enhancement would be to make it configurable. Throwing an exception should be the default behavior.

Related issues:

  • NH919: Serialized object gets truncated (...), version 1.0.2

  • NH2484: (...) Binary Blob SerializationException (...), version 3.0.0.GA

  • NH699: StringType properties are silently truncated. version none

  • NH2302: (...) nvarchar(max) (...) causes string truncation, version 3.0.0 alpha2, fixed in alpha3

  • may be some more.

Environment

None

Activity

Show:

Oskar Berggren 
June 6, 2013 at 2:35 PM

Please don't use the issue tracker for support questions, direct those to the nhuser mailing list instead where a wider audience might be able to help. In this case, look for more details in the full exception data.

Former user 
June 6, 2013 at 2:17 PM

Hi Oskar,

We are facing an exception while using Nhibernate 3.3.3.GA product version, which says "The length of the string value exceeds the length configured in the mapping/parameter."

and this is happening after we have upgraded the Nhibernate version from 3.1.0.4000 to 3.3.3.GA version.

I am facing this problem, even after having the length on the column defined.

<property name="OldValue" type="string">
<column name ="OldValue" length="2147483647" not-null="false" />
</property>

and definitely the length of the string is not exceeding.

Any fix or workaround?

Oskar Berggren 
May 30, 2012 at 6:31 PM

Closing issues fixed in 3.3.1.CR1.

Oskar Berggren 
April 27, 2012 at 7:54 AM

To summarize and clarify the intended behavior in 3.3GA:

SchemaExport use the defined length and create nvarchar(max) if longer than 4000 characters (report a bug if this is not the case).

SQL string parameters will have their size rounded up to 4000 characters, unless more is required in which case it will be rounded up to Int.MaxValue/2 (on ms sql server).

When setting the value of a string parameter, NHibernate will throw if the string is longer than the defined length of the string parameter to prevent ADO.NET from performing silent truncation of the string. This happens only if the driver actually sets the length of the string parameter - if it doesn't, the behavior is defined by the database engine itself.

Richard Brown 
December 2, 2011 at 10:51 AM

I've merged your changes as-is (using the IDbDataParameter size). This gives the driver the option to not set the size, or set it to a larger value as you suggested.

I suspect we should only create a setting if we are asked - and even then, I'm not sure we should allow an option to silently delete the data.

Thanks for the fix.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Who's Looking?

Open Who's Looking?
Created February 3, 2011 at 6:15 AM
Updated June 6, 2013 at 3:08 PM
Resolved December 2, 2011 at 10:52 AM
Who's Looking?