I am trying to import/use Northwind db in my Laravel project.
Since when creating Laravel project you're required to create models, migrations and such, i want to ask, is there some automatized way of importing it, with model and migration creating, or that is only doable by hand?
Another question: I tried adding foreign key constraint to one the tables, and also tried tried to migrate that specific change by creating subfolder in migrations:
php artisan migrate --path=/database/migrations/north/
where "north" is subfolder in which is specific migration is located and
Schema::table('order_details', function (Blueprint $table) {
$table->unsignedBigInteger("OrderID")->nullable();
$table->foreign("OrderID")->references("OrderID")->on("orders")->onDelete("cascade");
});
is code for creating foreign key.
Questions:
Is there automatized way for importing Northwind or any db not created in Laravel, or i have to do all by hand?
If i have to do by hand, then why the way of adding fk constraint doesn't work? Am i missing something? Explanation: When i try to migrate, it says: "Nothing to migrate".
Related
I have a fresh Laravel installation and I've added Cashier to my project.
Since the Users model on my app won't have a stripe connection, but rather an Accounts model, I need to alter their migration to add columns to Accounts instead of Users
The documentation says to run:
php artisan vendor:publish --tag="cashier-migrations"
which adds the two migration files to database/migrations
From there I can change users to accounts in the migration file.
When I try to run php artisan migrate, I get:
Whoops\Exception\ErrorException : Cannot declare class CreateCustomerColumns, because the name is already in use
This problem only goes away when I delete the migration files, but then the new columns are added to users.
The documentation states that you can disable their migration files by putting Cashier::ignoreMigrations(); in AppServiceProvider
I didn't realize that's what I wanted to do. I thought the publish command only published the two files I needed to edit, however, those are the only migration files that come with Cashier.
Be sure to add Cashier::ignoreMigrations(); in the register method.
And add use Laravel\Cashier\Cashier;
The file (and thus the class) must exist twice, probably in your database/migrations directory, most likely with 2 different datetime prefixes on the filenames.
I am trying to make a relationship between "user_id" in members table and "id" in users table. Getting errno: 150 "Foreign key constraint is incorrectly formed". I am migrating users table before the members table.
$table->integer('user_id')->unsigned()->nullable();
$table->foreign('user_id')->references('id')->on('users');
Your syntax is correct, so it's likely one of a couple problems:
Your users table is not actually called users.
You actually created the members migration before the users migration, and then went back and edited the members migration. Laravel runs migrations in the order of the timestamp in the filename, so you'll need to either edit the file name of your members migration, or create a new migration with your foreign key definition in it.
You're trying to run existing migrations over the top of an existing database. Run php artisan migrate:refresh to roll everything back and run it all over again. Be aware, this will destroy all your data, so make sure it's in a test environment.
I created some migration files which created the table "users" and "user_info".
Running php artisan migrate created the tables and added them to the migrations table in the database.
Then I needed to create a new column and add some new rows to the user_info table. So I created a new migration file with the same name as the first migration file which was used to create the "user_info" table.
Since Laravel adds a timestamp to the file I didn't think that would create any problems. However, in the the new migration file I used the same class name as for the the first migration file, did the changes I wanted and finally ran php artisan migrate again.
That seemed to create problems since I got an error saying that the class name was already in use.
So I changed the migration filename to be user_info2 and used the class name UserInfo2 and tried again.
This time it worked and the batch has been bumped up to 2 in the migration table in the database.
But how does Laravel know that the migration file actually is related to the first user_info migration file since I changed both the filename and class name? I thought they had to have the same name in order to make Laravel have control of the "batch-value".
Thanks for any help!
The batch number of the migrations is used to specify multiple migrations that were created while running php artisan migrate.
So for example you create two migrations: users and user_info you run php artisan migrate this two migrations will be created and will be referenced by the same batch number: 1.
Then you create another migration, when you migrate this migration will have the number 2 as batch number.
When you do php artisan migrate:rollback based on the batch number Laravel knows which migrations to rollback, in this case only one migration with the batch number of 2.
So batch in this terms means an array of migrations that has not been run. Those will be referenced by the same ID, in order to make the rollback possible.
Hope this explains a bit more.
I have played with Entity Framework 4.3 migrations for some time now, but I have trouble achieving the next behavior: In case my code runs on an existing database, I want the database to be migrated automatically to the latest version, but in case the database doesn't exist, the database should be created automatically from the migrations.
I think the problems is related to the first migration that you create. If you create the first migration using -IgnoreChanges parameter (or manually delete them as explained here: http://thedatafarm.com/blog/data-access/using-ef-migrations-with-an-existing-database/), you will not be able to use migrations in order to create a new table using the DbMigrator class. because you don't have the initial migration. If you create the first migration without using -IgnoreChanges, than the migration of the existing database will not be possible. Does anybody has any solution for this problem?
So you have existing database and you want to use migrations on that database and in the same time you want to support database creation by migrations in case of new deployment?
It looks like little bit unsupported use case. The simplest in this case (not tested) would be either conditional compilation or conditional migration driven by some AppSettings key. It means creating initial migration as if you don't have the database and modify Up method to:
public override void Up() {
if (ConfigurationManager.AppSettings["NewDatabaseRequired"] == "true") {
// Here is generated content
}
}
or
public override void Up() {
#if NewDatabaseRequired
// Here is generated content
#endif
}
There is plenty of other more complicated options including scripting your current database, modify the script to end if tables already exist, add a script as a resource to your migration assembly and execute the script in the Up method generated with -IgnoreChanges.
As another option you can open additional database connection and check if tables from migration already exists (by querying sys.tables view in SQL Server). This will not need generated script.
I am new in MVC3 i am going to create a MVC3 test project where i am create model class name WhiteAccount with ID,Name,Email,Password property. and successfully create a DB but when i add another new property in that WhiteAccount model class and in my DB table too but it give me some error. Some people say just delete the EDMmetadata table from your DB, But Here is the problem i have no EDMmetadata table in my DB ! I create my DB by EntityFramework v4.3.1 system automatically (CodeFirst). What should i do now ?
Check for the __MigrationHistory table.
Open the nuget package manager console and run
update-database -script
It will likely give you a message about having to enable it first, follow those directions
Run: Enable-Migrations
some more info on migrations
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
Im gathering this table is there in your db (under system tables) and it contains your model information. Since your project changed you need to tell the migrations about the new field or delete the table (__MigrationsHistory)