I was having this issue but just pulled latest from trunk and it seems
to be fixed now. :)
On Jan 18, 11:53 am, Jon wrote:
> Is anyone else still having this issue, or is it just me? It's exactly
> as Neal describes - when I have the Version property in the base class
> it doesn't work, and when
Welcome :)
When in doubt, throw implementation stuff (like Id and Version) on the base
class for everything and forget about it :)
On Mon, Jan 18, 2010 at 11:42 AM, Jeff Doolittle wrote:
> Thanks Hudson, that makes total sense. I'm pretty satisfied already
> since the latest build fixes the bas
Thanks Hudson, that makes total sense. I'm pretty satisfied already
since the latest build fixes the base-entity version problem. I can
probably live with one extra property on my entities since I've been
able to move most of the auditing properties to my component class.
--Jeff
On Jan 18, 9:3
>
> What I'd really like to do is put my version property on a component
> class.
That's an NH thing, not specifically a FNH thing. Head over to nhusers and
they might be able to help you out a bit more. But this sort of thing I'm
almost positive isn't possible. Your audit columns are business en
I downloaded the latest build (614) and I was able to add a Version
property to a base class, as described by Paul Batum.
I'd like to add another wrinkle to the mix.
What I'd really like to do is put my version property on a component
class. I already have a component class for audit columns lik
Is anyone else still having this issue, or is it just me? It's exactly
as Neal describes - when I have the Version property in the base class
it doesn't work, and when it's in the subclass it works fine. As
Deesky says, having to create an override for every entity class seems
to defeat the point o
My understanding is that this is fixed. I'm using an automapped base
class with a Version property and it works fine.
On Thu, Jan 7, 2010 at 7:51 AM, Jeff Doolittle wrote:
> Does anyone know if a fix for this if forthcoming?
>
> --Jeff
>
> On Nov 13 2009, 10:18 am, Billy wrote:
>> I agree with D
Does anyone know if a fix for this if forthcoming?
--Jeff
On Nov 13 2009, 10:18 am, Billy wrote:
> I agree with Deeksy. The version property from a superclass was
> mapping automatically previously. Seems to require a manual mapping
> now or it gets completely ignored.
>
> Billy
>
> On Nov 5,
I agree with Deeksy. The version property from a superclass was
mapping automatically previously. Seems to require a manual mapping
now or it gets completely ignored.
Billy
On Nov 5, 10:58 pm, Deeksy wrote:
> This seems to be a bug introduced in (or some time before) 1.0 RTM. I
> was using a
This seems to be a bug introduced in (or some time before) 1.0 RTM. I
was using a previous version and the Version property in the base
class was being set up as a in the mapping file.
Creating an AutoMappingOverride for each class defeats the point of
having the Version column in the base clas
Chanan,
you need to create an IAutoMappingOverride for each mapped type, these
look something like:
public class QuestionAutoMapOverride :
IAutoMappingOverride
{
public void Override( AutoMapping mapping )
{
mapping.Version( question => question.Version )
Hi Neal,
I just found the same problem... Version seems to only wotk when
declared in the Entity class and does not when declared in the Base
Class.
By the way, would you be so kind as to post your Mapping override
code, its been a long day... :)
Thanks,
Chanan.
On Oct 18, 7:30 pm, Neal Blomfi
12 matches
Mail list logo
