To be honest I think it's entirely possible to have hundreds of tests without checking "is silent truncation of this field blocked" for every property. :)
Anyway, I've attempted a patch for this, including a test case and all existing tests pass. What problems can you see with this? https://github.com/obbe80/nhibernate-core/compare/master...NH-2528 /Oskar 2011/11/16 Fabio Maulo <[email protected]>: > Just to write what should follow the last "...": > especially when there isn't a single test in such application. > > On Wed, Nov 16, 2011 at 4:43 AM, Oskar Berggren <[email protected]> > wrote: >> >> https://nhibernate.jira.com/browse/NH-2528 >> Throw exception instead of silently truncate string and blob data >> >> In NHibernate 3.1, mapping a property with a string and e.g. length >> 10. Setting the property to a string of length 20 will trigger no >> exception but instead silently truncate the string to 10 characters. >> >> In the issue report it is argued that this behavior is the behavior of >> the DataProvider and that NHibernate shouldn't change that. To me this >> seems like a bad position to take, since it means that by default >> NHibernate and the system may destroy data. The users data should be >> sacred and the least destructive alternative should be the default. >> The application developer can then make an informed decision and >> enable silent truncation where relevant. >> >> As it is now, there is a big risk that the problem will only surface >> much later, after having already destroyed a bunch of data... >> >> >> /Oskar > > > > -- > Fabio Maulo > >
