[fluent-nhib] Re: Meaningful exception messages - r179 follow up

I personally feel it's almost always better to favor extension methods especially if it's targeting your own classes, when they target .Net framework types or 'object' that's when it becomes shakey whether or not it's good for the API IMO. --~--~-~--~~~---~--~~ You

[fluent-nhib] Re: Meaningful exception messages - r179 follow up

Implemented :) The only difference being that I went with an extension method over a separate helper class. Not sure whether this is a better or worse design decision, but I'm not a big fan of helper classes either. On Sat, Jan 3, 2009 at 9:42 PM, James Gregory wrote: > All good suggestions. I'll

[fluent-nhib] Re: Meaningful exception messages - r179 follow up

All good suggestions. I'll look at this soon. On 1/3/09, emeric.fer...@gmail.com wrote: > > Hello, > > In order to keep on having more meaningful exception, one could try > the following refactoring : > > -Extracting private method PersistenceSpecification.CreateInstance() > into some helper cla

[fluent-nhib] Meaningful exception messages - r179 follow up

Hello, In order to keep on having more meaningful exception, one could try the following refactoring : -Extracting private method PersistenceSpecification.CreateInstance() into some helper class (maybe InvocationHelper) public static object CreateInstance(Type type) {

[fluent-nhib] Re: UseReflectionOptimizerKey = "use_reflection_optimizer"

I believe that was the case with NHibernate 1.2.1, but as of 2.0 I know they've changed the names. According to the NHibernate 2.0 knol what we're using is correct: Optional Configuration Properties

[fluent-nhib] Non-public constructors with the PersistenceSpecification

Hey guys, Just a heads up. The PersistenceSpecification had a new() generic constraint for the entity type, this meant that your entity had to have a public parameterless constructor. For those individuals that are using private or protected constructors, this was causing a problem. I've removed th

[fluent-nhib] Re: Automap version issue

Sounds, like a fair change. It's probably worth making the same check for timestamp as well then. As again I think it just checks the name. Andy On Sat, Jan 3, 2009 at 11:54 AM, James Gregory wrote: > I've just committed a change that limits the types of version to int and > long. > > > On Sat, J

[fluent-nhib] Re: Automap version issue

I've just committed a change that limits the types of version to int and long. On Sat, Jan 3, 2009 at 11:10 AM, Ayende Rahien wrote: > int and long > > > On Sat, Jan 3, 2009 at 12:34 PM, James Gregory wrote: > >> That sounds reasonable, but which types should be treated as a version? >> >> On Sa

[fluent-nhib] Re: Automap version issue

int and long On Sat, Jan 3, 2009 at 12:34 PM, James Gregory wrote: > That sounds reasonable, but which types should be treated as a version? > > On Sat, Jan 3, 2009 at 9:25 AM, Ayende Rahien wrote: > >> I have an entity that has a property called version, of type string. >> FN tries to treat thi

[fluent-nhib] Re: Automap version issue

That sounds reasonable, but which types should be treated as a version? On Sat, Jan 3, 2009 at 9:25 AM, Ayende Rahien wrote: > I have an entity that has a property called version, of type string. > FN tries to treat this as a column, which fails. I think that the > version check should be on na

[fluent-nhib] Automap version issue

I have an entity that has a property called version, of type string. FN tries to treat this as a column, which fails. I think that the version check should be on name + type, not just name. --~--~-~--~~~---~--~~ You received this message because you are subscribed