Uploaded image for project: 'NHibernate [Moved to GitHub]'
  1. NH-2528

Throw exception instead of silently truncate string and blob data


    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects versions: 3.0.0.GA
    • Fix versions: 3.3.0.CR1
    • Components: Core
    • Labels:
    • Sprint:


      (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.


          Issue links



              • Assignee:
                flukefan Richard Brown
                stefan.steinegger Stefan Steinegger
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created:

                  Who's Looking?