Is it possible to recreate a database view using a migration? Migration that was used to create a view on database is no more as per the changes done in some table structures. How do I recreate a view as per the new design? Do I have to drop the existing view and create a new through the migration? Or is there a simpler way without losing data?
If you're talking about a view stored in the database, the usual technique in Rails would be not to do that but use scopes in your ActiveModel instead. This next statement is more with MySQL specifically in mind, but probably true generally: as long as you have the indices properly set up, that approach should be as fast as having a view in the database itself and be more programmatically easy to work with. You can specify calc'd fields in a scope through SQL statements if appropriate, though the usual response to that idea is why not have that be an accessor function in your model (as if it were in the database).
Does this help or am I answering a different question than you had?
Related
I am learning entity framework. I am reading through some tutorials about initialization and how there are
CreateDatabaseIfNotExists
DropCreateDatabaseIfModelChanges
DropCreateDatabaseAlways
Custom DB Initializer
to choose from.
This makes me wonder, what does one do when they want to change the schema, but they want to keep the data they have?
I was just using sql directly, I could make temp tables, move stuff over, recreate the table with new columnns, move stuff back, etcv
What do you do when your classes and/or their relationships change in EF?
I think your looking for EF migrations:
https://learn.microsoft.com/en-us/ef/ef6/modeling/code-first/migrations/
for every schema change you create a migration, where you can add or remove tables or columns, or you can even run your custom script.
Each migration has an Up method, these will be applied if you run your migration, and a Down method this is used if you want to roll back to the previous migration for some reason.
With Update-Database you can apply all migrations, and with Update-Database –TargetMigration:{nameOfMigration} you can migrate to a specific version.
When you rename a database table via a Rails 4.2 migration that is actively in use every second (say a CarSales table for a car company), does Heroku handle that renaming gracefully - in a way that you don’t have to worry that while you’re writing to table “OldName” you’re not going to lose data while you’re renaming it to “NewName”?
According to the alter table docs for PG9.5 states that in general that
An ACCESS EXCLUSIVE lock is held unless explicitly noted.
As for RENAME:
The RENAME forms change the name of a table (or an index, sequence, view, materialized view, or foreign table), the name of an individual column in a table, or the name of a constraint of the table. There is no effect on the stored data.
Which makes it sound like accessing the table will not be permitted while the table is being renamed.
The biggest potential problem to this change is the rails side: Is the table backed by a model? Will you be Adding a new model to match the new name or using table_name to change the expected
The combination of model changes + lock that will be required, it may be difficult to perform all of the necessary operations with 0 downtime. If that is a strict requirement the change may be more difficult.
I'm using a code first approach to a simple web application: currently just a single table of book reviews.
I modified the model to include an extra column ("Rating"), and I also have an initialiser which correctly rebuilds the database every time I change the schema.
The problem is that none of the CRUD Views are updated to reflect the new "Rating" column. Do I have to modify each View by hand, or is there a simpler way?
Yes, you have to manually add them. Scaffolding is intended for simple set up of views / controllers only.
I'm starting to use Redis, and first thing my code is not too DRY, and was going to consolidate it in the application.rb and controller. Is this the best way to go, or should I make a new Class called Redis, and have all the logic in there?
My models are currently Customers, Orders, Products, and I'm using a lot of counters.
You will probably need a combination of new and existing model classes.
In many cases you can just drop the model used by the view directly into the datastore, which saves repetition. However, there will always be some places where the needs of the view and the datastore are different.
For example a property that appears as a list of values in the view may need to be stored as a separate set key rather than serialized with the other properties of the model.
Is there a way when i add a new entity to my Code First configuration the table gets automatically added so i don't have to worry about updating my DB with new tables?
you can add
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<YourDbContext>());
in you r application start . It will recreate database for you if you have modified your configuration.
And if you do not want to drop and create database (To incremental development) you can use SqlMigrations. http://www.hanselman.com/blog/EntityFrameworkCodeFirstMigrationsAlphaNuGetPackageOfTheWeek10.aspx
From: http://blogs.msdn.com/b/adonet/archive/2010/12/06/ef-feature-ctp5-code-first-walkthrough.aspx
Setting an Initialization Strategy
In the next section we are going to start changing our model which in turn means the database schema needs to change as well. Currently there is no ‘out of the box’ solution to evolve your existing schema in place. Database evolution is something we are currently working on and a sample of the direction we are heading is provided in a recent design blog post.
There is however the opportunity to run some custom logic to initialize the database the first time a context is used in an AppDomain. This is handy if you want to insert seed data for test runs but it’s also useful to re-create the database if the model has changed. In CTP5 we include a couple of strategies you can plug in but you can also write custom ones.
Add a using statement for System.Data.Entity.Database at the top of Program.cs
using System.Data.Entity.Database;
For the walkthrough we just want to drop and re-create the database whenever the model has changed, so at the top of the Main method in my Program class I’ve added the following code
DbDatabase.SetInitializer<ProductContext>(
new DropCreateDatabaseIfModelChanges<ProductContext>());