For ORM classes, it is common to add custom columns, even tables after deployment.

I know DO is supported by PostSharp. So I am wondering whether this is supported automatically.

For DO supports for legacy database schemes, it should be very easy to extend ORM classes by adding extra columns, even extra tables before loading, by the help of PostSharp.

I searched this website and the manual and I couldn't find this feature.

Can someone confirm it? Of course, it is better to show how to do it.

Thank you in advance,

Ying

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

asked Aug 01 '10 at 13:34

Editor's gravatar image

Editor
46153156157

edited Sep 03 '10 at 16:12

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412


One Answer:

Are you asking about the possibility to operate with legacy database having some additional columns in tables (in comparison to mapped ones), or about the possibility to (re)generate Entities (their C# files) for it?

First case is supported in "LegacySkip" upgrade mode, if default value is provided for such columns.

Second case is not supported - at least, currently. Although this feature is in our near-time TODO list.


AOP is helpless here - emitting custom types is actually pretty far from typical problems solved by AOP. Btw, PostSharp injects aspects at compile time.

I don't see any serious reasons to emit the classes at runtime:

  • DO4 isn't much interested in your own types. It relies on its own model, that, being originally built using reflection, can be modified in IDomainModule.OnDefinitionsBuilt event.

  • Most likely, your own code won't be able to deal with user-defined types as well - simply because it doesn't know them at the moment it gets compiled.

But this doesn't mean this can't be done. E.g. you can emit the types, that are descendants of your own types (likely, there must be something common ;) ), using C# CodeDOM, and make DO using them further.

I also recommend you to seriously think, if this is really necessary: such a solution will significantly increase the complexity. Probably, it's enough to implement a typical Entity-Property-Value model implying no changes of schema in runtime. if typical case is adding few user-defined columns, such complex solution seems unreasonable. Also note, that schema is normally a bit more then just columns and tables - e.g. there are indexes.

answered Aug 02 '10 at 10:30

Alex%20Yakunin's gravatar image

Alex Yakunin
29714412

iDarwin wrote: I mean the second case. But for you use AOP, I expect the entity classes can be upgraded at run time without touch the source code. One scenario is I won't release source code to clients, but allow them to extend the database model after deployment.

(Aug 02 '10 at 10:30) Editor Editor'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

powered by OSQA