locked
Updating the Entity Framework at runtime RRS feed

  • Question

  • I was redirected from another forum...

    I have a couple questions about EF. I have not tried this yet so I am just asking.

    1. As you issue data store updates from development to production how do you update the EF to get those changes ( new exe with those updates to data store )? Do you only have to regenerate the EF ( and classes ) in the solution or is there much coding involved to pick up changes?

    2. If I have a database that allows the users to add columns and/or tables with columns ( no deletions ) at run time can the EF handle these modifications to the underlying data store  without much tweaking or is this asking too much? Can you regenerate the EF and its classes in code at run time?

    I have started playing with this and it is pretty swift but I can see thses scenarios arising in our developement process.
    Wednesday, April 29, 2009 3:41 PM

Answers

  • Michael,

    Not sure I understand points 2 and the follow up scenario correctly, but I guess this information might be useful.

    In addition to what Jiri mentions, EF at runtime actually uses 3 separate model artifacts to resolve how to query and update the database. The conceptual schema (usually a .CSDL file) describes the object model you use in your application, the storage schema (SSDL) describes the model in the database. A third file (MSL) describes how both storage and conceptual schema have to be mapped. Using tools like the Entity Data Model designer will generate a single file EDMX that contains the other three, and by default, during build, the three files will be embeded in the output assembly as resources, but this is not the only option. You can also output the three files to the output directory and point your EntityConnection to them as external files (in the metadata section of the connection string).

    Then, when you make changes to your database schema you can tweak the SSDL and the MSL independently of the conceptual model and without recompiling your code. In practice this involves manipulating XML files, which sometimes can become a burden, but it provides certain level of isolation between changes you do to your database schema and your application, which is what I think you are looking for.

    Hope this helps,
    Diego


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, May 1, 2009 4:40 AM

All replies

  • Any EF gurus out there?

    A follow up scenario is you might have X number of clients hitting one database instance ( or replicas sync'ing with master ) and a database update is issued at the server. How does that change get propagated to all the clients' EF mappings. Detecting the change is not an issue that can be done through versioning of the database. Would you have to basically update your copiled code to update your EF mapping back to your new database schema?


    Thursday, April 30, 2009 1:32 PM
  • Hi *,

    1> You can place your model and entities into separate assembly. When updating database, ship just this DLL (and maybe new app.config to redirect versions).

    2> Well, you can use the API co create all the stuff, same as i.e. EdmGen is using. But this will generate model coresponding 1:1 to database. Hence any of your changes will be gone. Either you create some merging facility or use different approach for this.
    Jiri {x2} Cincura
    Thursday, April 30, 2009 7:48 PM
  • Michael,

    Not sure I understand points 2 and the follow up scenario correctly, but I guess this information might be useful.

    In addition to what Jiri mentions, EF at runtime actually uses 3 separate model artifacts to resolve how to query and update the database. The conceptual schema (usually a .CSDL file) describes the object model you use in your application, the storage schema (SSDL) describes the model in the database. A third file (MSL) describes how both storage and conceptual schema have to be mapped. Using tools like the Entity Data Model designer will generate a single file EDMX that contains the other three, and by default, during build, the three files will be embeded in the output assembly as resources, but this is not the only option. You can also output the three files to the output directory and point your EntityConnection to them as external files (in the metadata section of the connection string).

    Then, when you make changes to your database schema you can tweak the SSDL and the MSL independently of the conceptual model and without recompiling your code. In practice this involves manipulating XML files, which sometimes can become a burden, but it provides certain level of isolation between changes you do to your database schema and your application, which is what I think you are looking for.

    Hope this helps,
    Diego


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, May 1, 2009 4:40 AM
  • Thanks. That is what I am looking for and a good place to start digging.
    Friday, May 1, 2009 2:37 PM
  • Our application gives the user the ability to add their own columns ( basically udf's ) to our tables at runtime. One of our new features is to allow them to add whole tables ( and columns to those tables ) at runtime. My question would be how to update the EF without recompiling to handle these changes and I believe you answered that by your suggestion to keep the EF files external and updating them as needed.
    Friday, May 1, 2009 2:41 PM
  • Michael,

    While you can change the storage model and the mapping independently of the application, if you need to change the conceptual model (i.e. to make new entities avaialable to the application, requires you to create the corresponding CLR types). Therefore I don't think you can get this without adding classes and recompiling. Currently, Entity Framework does not support using "property bags" as entities. Besides that, I doubt you can do even the simplest changes to metadata "at runtime" (strictly speaking), because we cache the metadata at various different layers in EF.

    Hope this answers your question,
    Diego
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, May 1, 2009 4:09 PM
  • Bummer. This is a functionality that we are required to have and may force us yo use traditional ADO.Net tools versus the EF, not what I wanted.
    Friday, May 1, 2009 6:29 PM
  • In fact, once the connection is established, the metadata is a read-only property.
    Friday, May 1, 2009 8:50 PM