Agreed, but it does happen, especially if some kind of scaffolding is used to generate CRUD interfaces, or if someone forgets to put validation logic in the domain. I know I've forgotten to put length validation in when I was in a rush, and the length check in the db has saved me a few times. It also allows me to be aware that there is a problem; I can be emailed the error or check the logs and be proactive about fixing it. With silent truncation I wouldn't know that something is wrong until much later in the process, and by then the problem can be difficult to debug or discover.
Just my two cents. I just think it makes our lives as developers a bit easier. From: [email protected] [mailto:[email protected]] On Behalf Of José F. Romaniello Sent: Thursday, September 23, 2010 9:30 AM To: [email protected] Subject: Re: [nhusers] Nhibernate 3 truncate behaviour I think it is a bad idea to send a longer string when you already know the length of the field...... With or without truncation. This is a validation rule of your domain. Why going to the database when you already know that is going to fail? 2010/9/23 Tyler Burd <[email protected]<mailto:[email protected]>> Maybe it's standard across other DB engines, or maybe I'm just missing something obvious, but silently truncating strings by default (and thus encouraging the practice) seems like a BAD idea to me... Tyler Burd -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Fabio Maulo Sent: Thursday, September 23, 2010 9:06 AM To: [email protected]<mailto:[email protected]> Subject: Re: [nhusers] Nhibernate 3 truncate behaviour No, it is not a bug istead it is a specific request to make happy MsSqlServer. If you want the old behavior you have to copy&paste the SqlClientDrive and disable the actual behavior, the you have to specify your implementation in the sessio-factory configuration. -- Fabio Maulo El 23/09/2010, a las 11:10, Maxim Filimonov <[email protected]<mailto:[email protected]>> escribió: > Dear Everybody, > I've played with Nhibernate 3 Alpha 2 for a while and recently found a > bit confusing behaviour at least from standpoint of compatability with > version 2.1.2. > A problem occurs when I try to insert(didn't try to update but I > suppose it can have the same problem) string value to column with > limited length. > In 2.1.2 when such insert occurs my db engine(MSSQL SERVER 2008) > throws an exception "String or binary data would be truncated." which > gives me ability to rollback transaction at least if business layer > didn't check length of a field. With the version 3.0 Alpha 2 db engine > doesn't throw any exception on such insert because value is truncated > automagically by nhibernate. Generated SQL: > 2.1.2: > exec sp_executesql N'INSERT INTO Customers (FirstName) VALUES (@p0); > select SCOPE_IDENTITY()',N'@p0 nvarchar(16)',@p0=N'MoreThan3Symbols' > 3.0: > exec sp_executesql N'INSERT INTO Customers (FirstName) VALUES (@p0); > select SCOPE_IDENTITY()',N'@p0 nvarchar(3)',@p0=N'Mor' > > My mapping: > <class name="TruncateBug.Customer,TruncateBug" table="Customers"> > <id name="CustomerId" column="CustomerId"> > <generator class="native"/> > </id> > <property name="FirstName" column="FirstName" length="3"/> > </class> > And the code that doesn't produce exception anymore: > var invalidCustomer = new Customer() { FirstName = > "MoreThan3Symbols" }; > int id = (int)session.Save(invalidCustomer); > > And yes session will contain Customer object with full length > FirstName which could lead to a lot of misunderstanding in further > usage of the Customer object in scope of this session. > > Maybe it's not a bug but a feature but then I hope there is a way to > configure nhiberate to throw exception as previously and to not try to > create magic for me. > > Thanks in advance, > Yours sincerely, > Maxim Filimonov > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to > [email protected]<mailto:[email protected]>. > To unsubscribe from this group, send email to > [email protected]<mailto:nhusers%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]<mailto:[email protected]>. To unsubscribe from this group, send email to [email protected]<mailto:nhusers%[email protected]>. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]<mailto:[email protected]>. To unsubscribe from this group, send email to [email protected]<mailto:nhusers%[email protected]>. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
