How do I map a property with no setter and no backing property fluently with NHibernate?

Question

Let's say I have the following entity:

public class CalculationInfo
{
    public virtual Int64 Id { get; set; }

    public virtual decimal Amount { get; set; }

    public virtual decimal SomeVariable { get; set; }

    public virtual decimal SomeOtherVariable { get; set; }

    public virtual decimal CalculatedAmount
    { 
        get
        {
            decimal result;

            // do crazy stuff with Amount, SomeVariable and SomeOtherVariable

            return result;
        }
    }
}

Basically I want to read and write all of the fields to my database with NHibernate with the exception of CalculatedAmount, which I simply want to write and not read back in.

Every similar issue and corresponding answer has dealt with specifying a backing store for the value, which I won't have in this scenario.

How can I accomplish this using Fluent NHibernate?

Thanks!

UPDATE: Here's what I've tried, and the error it leads to:

Here's my mapping for the property...

Map(x => x.CalculatedAmount)
      .ReadOnly();

And the exception it yields...

Could not find a setter for property 'CalculatedAmount' in class 'xxx.CalculationInfo'

Shulins

Answer 1

I figured out that the way get this mapping working in Fluent NHibernate is to simply add the Access Property:

Map(x => x.CalculatedAmount).Access.ReadOnly();

Geest

Answer 2

I don't use Fluent, but in the mapping a persisted property with no setter is mapped with access="readonly", so look for something like .Readonly()

(Readonly is from the model perspective; the value is written to the DB and used in dirty checks)

Scandent

I've updated my answer to address that...it was one of the first things I came across, but I still ended up with the exception above. Can you think of a setting in NHibernate that would block this from working? – Shulins

Can you export the XML that FluentNH generates? – Scandent

Answer 3

Looks like it's a calculated value. If you can calculate this value at any given time, then why store it at all?

Overbuild

Great question...the short answer is non-repudiation. Even if my method of calculation changes, I can always point to what was calculated at a given point in time / correlated to an action. – Shulins

@Brandon Linton: Fair enough. +1. Is there any reason why a private backing field is undesireable, or is it more of an issue of aesthetics? – Overbuild

it would just never end up getting used...the calculation should be performed every time, since the variable factors can change at any time. – Shulins

I have the same situation. I need to persist a read-only, derived value for reporting purposes. – Scottscotti