http://216.121.112.228/browse/NH-2144
On Mar 21, 3:47 pm, Fabio Maulo <[email protected]> wrote: > Please open a JIRA ticket. > Thanks. > > 2010/3/21 jason patterson <[email protected]> > > > > > > > Well, it is a breaking change, my code shows that. > > > My main problem with the change is that there is no reason why my > > mapping and code should not work. Now I have to use byte[] instead of > > double[] for BinaryBlob to work. That is not just a simple mapping > > change. What is the reason for not allowing Binary type to be larger > > than 8000 bytes? Sql Server can handle it just fine. > > > I am not trying to be difficult, but this will break a lot of existing > > code. My case is not unique. > > > On Mar 21, 1:54 pm, Fabio Maulo <[email protected]> wrote: > > > So is it not a potential breaking-change ? > > > If I well remind I have done the work to have all parameter size well > > > defined in all scenarios (any kind of size definition in the mapping) and > > I > > > have experimented some breaking change (exceptions in existing code). > > > As you saw, even if the problem Jason have reported has another possible > > > solution, the BR is there. > > > > btw... what is needed is: > > > - JIRA ticket related to the change > > > - actualization of releasenote.txt with the potential breaking change > > > > Thanks. > > > > 2010/3/21 Ayende Rahien <[email protected]> > > > > > This isn't a breaking change. We aren't preparing the SQL here, we are > > > > setting the parameter size, which isn't related to preparing the > > statement. > > > > The problem the user has run into was something that happened to work > > and > > > > that shouldn't have, not a supported scenario. > > > > > On Sun, Mar 21, 2010 at 8:36 PM, Fabio Maulo <[email protected]> > > wrote: > > > > >> Oren, > > > >> why this > > > >> //if (IsPrepareSqlEnabled) > > > > >> That is an explicit NH configuration setting, why do it by default > > > >> commenting a line ? > > > >> Why the user should not set the configuration property "prepare_sql" > > > >> explicitly ? > > > >> Which was the JIRA ticket related to that change ? > > > >> That is a know issue and a user have created even a wiki > > > >>http://nhforge.org/wikis/howtonh/tuning-queries-with-ms-sqlserver.aspx > > > > >> Why the solution shouln't be making virtual > > DriverBase.IsPrepareSqlEnabled > > > >> and leave the user override it in his own driver if he don't want use > > the > > > >> configuration property ? > > > > >> In practice... why introduce a potential breaking change when > > everything > > > >> is already supported ? > > > > >> 2010/3/21 Ayende Rahien <[email protected]> > > > > >> Yes, you need to use BinaryBlob for this. > > > > >>> On Sun, Mar 21, 2010 at 7:18 PM, jason patterson < > > [email protected]>wrote: > > > > >>>> Hi guys, > > > > >>>> Commit 4915 broke my code so I am trying to understand if my my code > > > >>>> was wrong or if the change is wrong. > > > > >>>> Here is the commit: > > >http://github.com/leemhenson/nhibernate/commit/f72aa7987d1f88f3d1aab1... > > > > >>>> I am storing a double[] as type=Binary to Sql Server. When the > > length > > > >>>> is greater than 8000 bytes, it fails with a serialization exception. > > > > >>>> My guess is that I need to modify my code to use BinaryBlob, but I > > > >>>> just want to make sure commit 4915 didn't cause any unexpected > > > >>>> changes. > > > > >>>> Thanks, > > > >>>> Jason > > > > >>>> Here's a sample mapping. > > > > >>>> <class name="Foo" > > > > > >>>> <id name="Id" type="Guid" column="Id"> > > > >>>> <generator class="guid.comb"/> > > > >>>> </id> > > > > >>>> <property name="Name" /> > > > >>>> <property name="Values" column="ValuesArray" length="1000000" / > > > > >>>> </class> > > > > >>>> And the code. > > > > >>>> public class Foo > > > >>>> { > > > >>>> public virtual Guid Id { get; set; } > > > >>>> public virtual string Name { get; set; } > > > >>>> public virtual double[] Values { get; set; } > > > >>>> } > > > > >>>> To unsubscribe from this group, send email to > > nhibernate-development+ > > > >>>> unsubscribegooglegroups.com or reply to this email with the words > > > >>>> "REMOVE ME" as the subject. > > > > >>> To unsubscribe from this group, send email to > > nhibernate-development+ > > > >>> unsubscribegooglegroups.com or reply to this email with the words > > > >>> "REMOVE ME" as the subject. > > > > >> -- > > > >> Fabio Maulo > > > > >> To unsubscribe from this group, send email to nhibernate-development+ > > > >> unsubscribegooglegroups.com or reply to this email with the words > > "REMOVE > > > >> ME" as the subject. > > > > > To unsubscribe from this group, send email to nhibernate-development+ > > > > unsubscribegooglegroups.com or reply to this email with the words > > "REMOVE > > > > ME" as the subject. > > > > -- > > > Fabio Maulo > > > To unsubscribe from this group, send email to nhibernate-development+ > > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > > ME" as the subject. > > -- > Fabio Maulo To unsubscribe from this group, send email to nhibernate-development+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
