Here is what I am trying:

[HierarchyRoot, Serializable]
    [TableMapping("CalendarEvents")]
    public class CalendarEvent : Entity
    {
        [Field, Key]
        public int ID { get; private set; }

        [Field]
        public int Year { get; private set; }

        [Field]
        public int Month { get; private set; }

        [Field(Nullable = false)]
        [FieldMapping("Year")]
        //[FieldMapping("Month")]
        public CalendarMonth CalendarMonth { get; set; }
    }

    [HierarchyRoot, Serializable]
    [TableMapping("CalendarMonth")]
    [KeyGenerator(KeyGeneratorKind.None)]
    public class CalendarMonth : Entity
    {
        [Field, Key(0)]
        public int Year { get; private set; }

        [Field, Key(1)]
        public int Month { get; private set; }

        [Field]
        public string UrlName { get; set; }
    }

Calendar and CalendarEvent are connected by the FK (Year, Month). How can I map this?

tobi


Updated at 11.08.2010 13:43:07

(Sorry for not answering for quite some time). I wanted to try this solution but I could not figure out how to map the CalendarMonth property to two db columns. I tried:

[Field(Nullable = false)]
        [FieldMapping("Year,Month")]
        public CalendarMonth CalendarMonth { get; set; }

and

[Field(Nullable = false)]
        [FieldMapping("Year")]
        [FieldMapping("Month")]
        public CalendarMonth CalendarMonth { get; set; }

but both did not work. Can you help out on how to map CalendarMonth to (Year, Month)?


Updated at 15.08.2010 10:33:17

Thank you for your very helpful offer! Here is my situation: I have decided to leave the sinking ship L2S and look for some other ORM. I like DO.NET very much because it became apparent to me by reading the manual that you guys really know what you are doing. So whenever I have time I do some testing with DO.NET to see if there are issues preventing a successful migration before I actually start the big work of migrating.

So far I have found only two issues: 1) I cannot map my existing database (and I always do database first because performance really matters for me and automatic upgrades are infeasible because of the data volume); 2) no join prefetching (yet).

1) I would thankfully take your offer of implementing the mapping of multi-column FKs because I would not want to change the DB schema as I then would also have to modify my existing ORM. 2) I have tried to made the case for this by email and will be sending additional info in a minute (I did some benchmarks today).

I would also point out that the query translator is really capable as I could execute some crazy queries ;-) Performance of compiled queries is also extremely good (350us for a 3 columns fetched by PK). All in all a superior product. What do you think about the two issues I posted above?


Updated at 18.08.2010 15:54:32

Very helpful, thank you. Please note that the first issue is a blocker for me that prevents me from pulling DO into production. I can live without the join fetch for a few month as I probably will implement that myself meanwhile in a hacky fashion on top of IQueryable.

This thread was imported from our support forum. The original discussion may contain more detailed answer.

asked Aug 02 '10 at 15:21

tobi's gravatar image

tobi
13556

edited Sep 03 '10 at 16:14

Alex%20Yakunin's gravatar image

Alex Yakunin
29713412


One Answer:

Do this as you'd do this in OOP:

  • Replace Year and Month in CalendarEvent to CalendarMonth reference

  • If you need Year and Month there, extract them from CalendarMonth.Key (or, as I advised earlier, from internally stored Key).


There is no way to specify exact column names for composite FKs now: you can control only prefix (i.e. "CalendarMonth" in this case), but suffixes are always the same as original PK column names, i.e. in this case you'll always get names like "Something.Year" and "Something.Month".

If you really need this feature, we can implement it ASAP - that's pretty easy, but since it isn't necessary in "standard" scenario, we postponed it. There is similar issue for EntitySets with implicitly created item type:

So if we'll decide to implement an issue with FK column names, this one can also be implemented. AFAIK, these are the only cases where you can't fully control mapped names.


First of all, thanks for expressing your positive opinion about DO - we're always happy to hear this :)

Issues created:

Hopefully, that's reasonable. Probably, the first issue will be implemented even earlier (i.e. in one of nearest v4.3.X updates). Concerning the second one - let's see. As I wrote, we're ready to re-prioritize it, if this will be really vital for someone.


Clear - we'll try to implement it earlier then. We already planned our works for the most part of the next week, so the most optimistic date is ~ 1st of September.

For now I can only recommend you to follow DO4 naming rules, and rename the columns when this feature will be available. Of course, this will work only if this is acceptable.

answered Aug 02 '10 at 20:58

Alex%20Yakunin's gravatar image

Alex Yakunin
29713412

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:

×568
×52
×23
×10

Asked: Aug 02 '10 at 15:21

Seen: 2,967 times

Last updated: Sep 03 '10 at 16:14

powered by OSQA