I'm working on proof of concept application like crm and i need your some advice.
My application's data layer completely dynamic and run onto EF 3.5. When the user update the entity, change relation or add new column to the database, first i'm planning make for these with custom classes. After I rebuild my database model layer with new changes during the application runtime. And my model layer tie with tightly coupled to my project for easy reflecting model layer changes (It connected to my project via interfaces and loading onto to application domain in the runtime).
I need to create dynamic entities, create entity relations and modify them during the runtime after that i need to create change database script for updating database schema. I know ADO.NET team says "we will be able to provide this property in EF 4.0", but i don't need to wait for them.
How can i update database changes during the runtime via EF 3.5 ?
For example, i need to create new entity or need to change some entity schema, add new properties or change property types after than how can apply these changes on the physical database schema ?
Any ideas ?
This blog post may have what you need. It describes a way to capture the metadata of your model and modify it in-transit, during runtime. I haven't a clue how it works, but it sounds cool.
Changing Entity Framework storage DB schema during Runtime
http://blogs.microsoft.co.il/blogs/idof/archive/2008/08/22/change-entity-framework-storage-db-schema-in-runtime.aspx
Related
I have two different applications (two different solutions) using the same database. Each application has its own set of models/tables used in it.
The .NET solution for Application 1 was created a year back and has evolved till today. As part of this, some new models were created, migrations were added and updated in the database (SampleDatabase). This has its own DBContext class.
The .NET solution for Application 2 is a new one created a month back. This application also uses the same database (SampleDatabase). A few new models specific to this application were created, migrations were added and updated in the database. This has its own DBContext class.
Requirement:
Now, there is a requirement where one of the tables created and being used by Application 1 needs to be modified to integrate with Application 2 (i.e., a PK from an Application 2 table has to be placed as a FK in an Application 1 table.).
Challenge
To create a migration for altering the model from Application 1, a reference is needed to the PK table available in the other solution, which is not possible.
To create a migration for altering the existing model from Application 2, the existing model has to be copied to the Application 2 codebase. By doing so, if a migration is added, it generated only a CreateTable statement and not an alter as the DBContext does not know that the table already exists.
Question:
How do we manage to have migrations that is aware of things happening in the database from both the solutions?
Thoughts:
One way that I had in mind is to have a shared library project that can be responsible for all migrations to this database. Requirements for any application can be taken care by this project. But this has to refer the DBContext from both the application which is again a challenge.
Please let me know your thoughts and if anyone has faced such situation in your projects.
Thank You.
Need help! I am new to Core 2.0 and VS 2017 and haven't had much experience with MVC. I have an existing database that I need to use with a core 2.0 project at work. I was able to use the Scaffold-DbContect to initially create the domain models from the existing database.
However, the database developers are making changes to the database and adding new tables. I need to keep my domain models in sync with the database changes that are being made.
The only thing I can find on the internet is how to make changes to the model and update the database schema. However, I need to update the model from changes made to the database.
EF Core works on Code First approach. And You guys are following DB First approach together. So you should make changes in your code and then generate migrations accordingly, Otherwise, it will lead you in trouble.
You can use EF Core Power tool for generating the db changes at code side. But in this case you have to take care while generating migrations from code side.
I am working with sql server and entity framework in a web ASP.Net C# Project. I am working with "Database first" concept. This mean i draw my database structure from sql server management studio on my local development computer. I add fields, rename fields, add table, change type, etc in the life of my project.
What i want to do is to see what to do when i want to apply database structure changes on my production(s) server(s). Is there a way for entity framework to "detect" changes with a concept of migration versioning like in symphony doctrine ? I actually patch by hand by applying sql scripts on my production server.
Thanks
In all cases you need to do some development tasks
Depends on the entity framework model you are using,
Code first approach : then you can use the reverse engineering, you can find this extension online, you can use the Tools > Extensions and Updates to find it , or you can update your classes manually.
Model first approach: then right click inside the edmx and Update Model from database
I have the older version of the core data model of the released app. Now, in the next version of the app, I am migrating the core data model to new model. Is there a way to get the attribute values from the old model before actually migrating to the new version of the model or is there possibly a way to know if the migration is to be occurred.
When you migrate, Core Data actually moves existing values for you. If you're doing a relatively simple migration, such as adding or removing some properties, Core Data does its best to make the move as seamless as possible. In many cases, you won't need to make any changes other than set your new model. See my answer here for more.
Yes, it is possible.
To get the attribute values from the old model you'll need to create custom entity migration policies (NSEntityMigrationPolicy subclasses). Then in -createDestinationInstancesForSourceInstance:entityMapping:manager:error: you'll receive source instance, and it is completely up to you how to create destination instances from source instances.
There is a method to check if a given store is compatible with store coordinator model: -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:].
I'm currently migrating my sqllite application to using core data. When I created the data model I noticed that an attribute can be marked as and Identity property. Happily I marked that attribute as required and indexable only to find out that I have to supply the value myself or the insert of the entity fails, which kind of takes away from the idea of the data store providing the identity for me.
So if the identity property doesn't work like I thought it does, does anyone as any idea what its for?
Digging in the documentation and on this site it became clear that core-data as it's own identity object. Is this what I'm suppose to use? Is this how relations are created between entities?
The attribute which marks a property as an identity property in the modeling tool is in the Sync Services pane and is only used by Sync Services, not Core Data itself.
You aren't supposed to worry about CoreData's internal identity but rather manage your relationships by creating the proper relationship associations in the CoreData designer and associating actual objects rather than ids.