Home → Help and guidance →

Automapping calculated fields

MylesRip

18 May, 2010 03:12 PM via web

Admin Functions

• Edit
• Remove

When I switched to the latest build, 677, I started getting runtime errors on the Fluently.Configure statement for any properties for which I did not supply a setter ("Could not find a setter for property 'PropertyName'"). These are calculated fields that I don't want to persist to the database. I was able to handle this by adding "IgnoreProperty" overrides for each case.

I'm wondering if there is a good, easy way to tell FNH to assume that if I didn't supply a setter, I don't want the property persisted.

1. Support Staff 2 Posted by James Gregory on 18 May, 2010 03:25 PM

   

   The easiest way is to override ShouldMap(Member) in your automapping configuration. Something like the below should mean you use the default automapping rules except any that are read-only.

   public override bool ShouldMap(Member member)
   {
     return base.ShouldMap(member) && member.CanWrite;
   }
   

   This will exclude any auto-properties with a private setter, or field backed read-only properties though. The reason this change was made was to support exactly those things, properties that do have backing fields but don't expose a setter; unfortunately, we don't have a smart way of finding out whether a property actually does have a backing field, so we're just implying that you do.

   Admin Functions

   • Edit
   • Remove

2. 3 Posted by MylesRip on 18 May, 2010 03:38 PM

   

   I have some properties with protected setters.
   

   I also have read-only collection properties, but I've overridden these to map using field access.

   Will the approach above be compatible with these two situations?

   Admin Functions

   • Edit
   • Split
   • Remove

3. Support Staff 4 Posted by James Gregory on 18 May, 2010 03:45 PM

   

   Should be fine, yes. Only private setters (or no setter at all) are
   considered CanWrite==false.

   Admin Functions

   • Edit
   • Remove