Furthermore, I didn't realise that we had an "Entity" class in FNH still.
Its used a little in some tests, perhaps we should move it to the test
assembly.
On Wed, Oct 7, 2009 at 8:50 AM, Hudson Akridge wrote:
> as I understand, the Id shouldn't
>> be used as part of GetHashCode, since a transient
>
> as I understand, the Id shouldn't
> be used as part of GetHashCode, since a transient object may have been
> added to the collection, and it would have a null Id
That's not necessarily true. It all depends on your setup. A situation where
you were using Assigned ID's you could always rely on
I feel I should point out that these are implemented in
FluentNHibernate.Data.Entity (and, as I understand, the Id shouldn't
be used as part of GetHashCode, since a transient object may have been
added to the collection, and it would have a null Id). GetHashCode and
Equals are a bit tricky to do c
Hmm. Not necessarily. I could, say, add methods to the class-mappings
instead. That would probably gel with FH style more. Unfortunately, if
I wanted to have NaturalKey() available for each property, that would
require a very intrusive set of changes to the interfaces (I'm
guessing), and if it's o
It is not within the scope of the Fluent NHibernate project to be generating
an Equals and GetHashCode implementation. I suggest you take a look at sharp
architecture if you haven't already - they do something along the lines of
what you describe in terms of providing attributes that allow you to d
Do you really want to decorate your class with fluent-nhibernate attributes?
On Tue, Oct 6, 2009 at 12:48 AM, craigp wrote:
>
> Hi -
>
> I'm fairly new to fluent-nhibernate; it's looking very good (*finally*
> an elegant api for C# db code).
>
> I'd like to have some way to automatically implem
