Question

Hello!

I have a model with several foreign keys. And I want to have an association field and foreign key field, something like this:

    [FieldMapping("WS_ID")]
    [Field(Nullable = false)]
    public int WorkShopId { get; set; }

    [Field(LazyLoad = true)]
    public WorkShop WorkShop { get; set; }

Point is, that correct declaration is like this (as I think):

    [Field]
    [FieldMapping("WS_ID")]
    public WorkShop WorkShop { get; set; }

But in this case I won't be able to get access to the field WorkShopId, and I need this possibility.

Found similar questions

http://support.x-tensive.com/question/5205/include-foreign-key-id-properties - but is this solution good for accessing this field in queries?

http://support.x-tensive.com/question/1782/foreign-keys-fieldsassociations - and here I cant figure out if this is possible :)

So, can I declare both fields: association and foreign key?

Thank you in advance!

UPDATE: here's screenshot with 2 different fields:

Accepted Answer

Hello Egor,

it's not possible to have a separate persistent field for accessing referenced entity key.

For regular operation (i.e. outside queries) you could use approach with calculated field that uses Entity.GetReferenceKey. This would not work out of the box for queries.

There are many options to handle such access in queries, let me name a few:

1) Use place.WorkShop.Id directly. LINQ translator is smart enough to avoid joins for accessing key fields of referenced entities.

2) Use some LINQ extension technique to provide support for your ReferenceId properties. For example it's possible to write a custom compiler for non-persistent properties, see this chapter of manual for examples (you'll need "Writing custom LINQ expression rewriter" section). Writing custom compilers is simplest solution however it requires repeating code for each ReferenceId property.

3) As alternative you could implement IQueryPreprocessor interface and register implementation in DomainConfiguration.Types. This would allow you to implement general transformation code, however this requires some proficiency with LINQ expression trees. Our localization extension uses this approach to translate access to localized properties. See its code for example.

Bonus suggestion

There is no need to declare reference fields as lazy load ([Field(LazyLoad=true)]). They are always treated as lazy loaded.

Subscription:

Related questions