I have a database that I created for a site using Entity Framework 4.1 code first. I need to add a simple property to one of my entity classes, and add a corresponding (possibly nullable) column to the database without losing any of the data in the database.
I think I can take down the site, alter the database to add the column, and redeploy website with an updated entity class, but I'm not sure that's the best way to do this schema upgrade.
Is there a standard (or just better) way of doing a schema upgrade on a DB that was created using code first?
Entity Framework Code First has a new feature in preview called Code First Migrations, which does simple schema upgrades.
You can check it out here http://blogs.msdn.com/b/adonet/archive/2011/07/27/code-first-migrations-walkthrough-of-august-2011-ctp.aspx
Related
I am using Entity Framework to handle the database in a server application. The server application is deployed to multiple nodes sitting behind a load balancer. I have now discovered the need to rename some of the tables and some of the table columns in the database. The problem is that I will need to do this without any down-time.
If I was writing my own database layer I could simply check the structure of the database and then run different code depending on if the database structure was upgraded or not and then I could potentially have 0% downtime.
Is it possible to do something like this in entity framework 4 or how do I actually make database changes in production with entity framework? I have searched the web for any solution but to no success. I have also considered having 2 entity framework instances in my app but the amount of code I have to write to switch between them would be far too much and error prone.
So to summarize the question:
Is there any way to rename tables and columns in a database in a production environment using Entity Framework 4 and without any downtime whatsoever?
EDIT
A new idea I got would be to create a view in place of the old table with the old naming scheme referencing the new table. I dont know if this will work. For it to work Entity Framework needs to accept this view like it would be a normal table. Could this be a good idea? Anyone tried anything like this with EF4 ?
Okay! Here is what thought I got -
Create new table in DB than renaming and build EntityFramework solution on that.
You need to deploy this by taking one server off from loadbalancer, update it,point entity framework code to new table structure and then again attach to loadbalancer.
Make the same procedure for all the servers in loadbalancer one by one. Once all are up with updated patch then sync old table and new table and then just delete old table. I am suggesting synching these tables so that you have all the data without data loss might happen in above process.
I am continuing the development of an android app that works against a server using maven, springframework and server database is MySQL.
need 2 very specific things:
I want to create a table
I want to create a trigger
But I want to create from springframework and maven and I could not find a way to do it.
Since it is a project among several people I want to be as automatic as possible to keep things simple.
I want to start when the server maven can create the table and the trigger if there are not exist.
It will be done?
I would like a simple example or a site I can visit and give me at least the concept of how.
Maven is a tool which builds your application. It's not available when the application runs. Therefore, it's often not the best choice to create database tables, etc.
A better approach is to locate the place where Spring's ApplicationContext is created and add code there that examines the database, finds out which tables already exist and create those which don't.
Later, you can extend the code to migrate data when your data model changes.
To execute SQL, check the Spring JDBC documentation and especially JdbcTemplate.
We are possibly looking at switching our tables, for views in EF 4.3.1.
We are using db first via the edmx file, so it generates our entities and dbcontext.
Has anyone got any tips for remapping our entities from tables to views?
Is this prone to disaster? We've had trouble with updating the edmx file in the past via the designer where the underlying changes weren't reflected deep somewhere within the code and we ended up with missing columns.
Or will views act very similar to tables in the EF world?
Designer handles views in completely different way - first of all all views used by EF through designer are read only unless you map stored procedures or custom SQL commands to insert, update and delete operation for each entity you want to modify.
Normally if you have updatable view you can simply modify SSDL part of EDMX and cheat it to pretend that the view is actually a table but this has two consequences:
You must modify EDMX directly as XML
You must not use Update from database any more because it always deletes whole SSDL part and creates a new one without your changes = you must maintain your EDMX manually or buy some extension for VS which will allow you updating only selected tables.
I have an application written in PHP/MySQL (symfony, to be specific) that I'd (potentially) like to rewrite in Rails. I know how to create scaffolding for tables that don't exist yet, but how do I get Rails to read my existing table structure and create scaffolding based on that?
Update: it turns out I can run the following command to get Rails to generate models for me:
rails generate scaffold Bank --no-migration
But it doesn't give me forms. I would prefer something that gives me forms.
The answer is db:schema:dump.
http://guides.rubyonrails.org/migrations.html
The easiest route is to pretend that you are writing a fresh app with a similar database schema - you can then create your models and migrations with the old schema in mind, but without being restricted by it. At a later stage, you can create a database migration script to copy all the old data into the new schema.
I'm doing this right now. The benefit of this approach is that you can take advantage of all of the rapid development tools and techniques provided by Rails (including scaffolds) without being slowed by trying to retrofit to the exact same schema.
However, if you do decide that you don't like this approach, and you do need to map your new models to existing tables, there are a number of configuration options provided by active record where you can override the convention over configuration naming patterns and map model names to tables names, set oddly named ID fields etc. For example:
class Mammals < ActiveRecord::Base
set_table_name "tbl_Squirrels"
set_primary_key :squirrel_id
end
The above will help Rails attempt to read your existing table, but success will depend upon how well the existing table structures matches Rails conventions. You may have to supply more configuration information to get it to work, and even then it might not work.
Finally, it may be worth considering the use of DataMapper which I believe is more suited to existing brownfield databases than ActiveRecord, because it allows you to map everything, but of course you will need to learn that API if you don't already know it.
Is there any possibility of changing the MySQL DB table's field name or adding a new field in Joomla in any project?
I need this information because I have to apply the Triggers for the tables.. Please Help
The core Joomla tables for 1.5 have been stable from 1.5.0 through the current 1.5.15. However, if you add any components to your Joomla installation, you will probably get new tables.
In the past, some components attempted to add fields the core Joomla tables, but most third-party developers have cleaned up their acts. Otherwise, no, the existing core table fields should stay the same.