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: screenshot

asked Feb 22 '13 at 05:09

esin's gravatar image

esin
9225

edited Feb 22 '13 at 06:04


One 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.

answered Feb 23 '13 at 05:23

Denis%20Krjuchkov's gravatar image

Denis Krjuchkov
179325

edited Feb 23 '13 at 12:40

Thank you very much, Denis! About lazy loading, as I'm new here, I prefer to write attributes like this explicitly (to understand your ORM better). Like in Entity Framework, where I have some experience. Thank you again for great and detailed answer!

(Feb 25 '13 at 04:50) esin esin's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

Subscription:

Once you sign in you will be able to subscribe for any updates here

Tags:

×9

Asked: Feb 22 '13 at 05:09

Seen: 2,330 times

Last updated: Feb 25 '13 at 04:50

powered by OSQA