I am trying to build an api in beego. I have to make a controller and a model for this project. Model has a database table but the table is not in my database. Beego automatically creates the table in the database. How can I stop it.
I imagine you are using this command err := orm.RunSyncdb(name, force, verbose). This command looks for changes in your models and if there are any drops the database and creates a new one. If you want to stop it simply don't use this command and write database migrations for your app with bee generate migration migration_name. In the file you have to run the required sql to create the tables. After writing your migrations run bee migrate -conn="{your_database_connection_string}".
Related
Is there a way to run EF Core migrations on multiple databases having the same set of tables. This is for multi-tenancy architecture where there's a master database (has metadata of all tenant databases including the tenant database connection string) and one database per tenant having the same set of database objects. We need to be able to run these migrations when a new tenant database is created automatically in SaaS model and also run these migrations whenever there are changes to the database structure (new columns, data type changes, new indexes etc.)
I've posted this exact same question on EF Core's GitHub.
The answer is, it can't be done at design time. You basically need to run your migration scripts manually on each tenant's database.
Executing migrations at runtime, however, is easy. You can instantiate a dbContext for each of your connection strings when your app launches (before WebHost.Run() if it's a web app) and execute your migrations like this: dbContext.Database.Migrate();
This is not ideal, of course, because it makes it harder for you to rollback your migrations to a certain point using Visual Studio Package Manager Console or CLI using dotnet ef commands.
The CLI command can be provided a connection string. So you could run it once per db, providing the connection string for each.
The command would look like this:
dotnet ef database update --connection "Server=client1.db;Database=client1"
Our team has about 10 developers, our application is one front-end connect to 20 databases(same scheme), and new database will be add when there is new client. Time to time someone will need update DB scheme, we end up doing this.
if you need scheme change, create SQL script and create the change request by email
only one person in the team run those script, and update database access layer
git push
tell the team dinner is ready
The person doing this created a EXE project for DB migration, he keep adding script to a folder, so the folder will contain all the script
0001.InitTables.sql
0002.MoreTabels.sql
0003.UpdateDropdowns.sql
.
.
.
then he use a library like DbUp (https://dbup.readthedocs.io/en/latest/) help him track those scripts and run on DB server.
He will run for DEV server first, on the release date, he will run this for production.
List<string> connectionStrings=new List<string>{
"ConStr1","ConStr2", "ConStr3"
};
foreach(var conStr in connectionStrings){
var upgrader = DeployChanges.To
.SqlDatabase(conStr)
.WithScriptsEmbeddedInAssembly(
Assembly.GetExecutingAssembly()
)
.LogToConsole()
.Build();
var result = upgrader.PerformUpgrade();
}
Is there a concise way to test Laravel migrations? I want establish the database up to the point of my new migration (including seeds etc) and then run my new migration and check the tests I have written for my seed data. The main issue is that I need to create my factory objects before the new migration is run, but after the other migrations run (creating all the original tables etc). As far as I know the only way to do it is either run every migration individually with the --path option, create the factory objects and finally run my new migration. Is there a better way?
I am using Code First, and I want to migrate it to ORACLE database, after multiple migrations process, I am getting this error,
The best overloaded method match for Oracle.ManagedDataAccess.EntityFramework.OracleMigrationSqlGenerator.Generate(System.Data.Entity.Migrations.Model.CreateTableOperation) has some invalid arguments
I'm facing the same problem
finally I solve it by opening the database and delete the migration_history table manually
and run the command again.
see at EF5 Code First - Changing A Column Type With Migrations
in each migration you will save a record in __MigrationHistory, so in case there is no sync between the code and the migration do the following:
delete the migration history table in the database.
migrate it again by create new migration 'in package manager console' add-migration data.
update the migration to database update-database
I am having a very bad situation here, working on a Laravel 5 project. previously developed by another developer. That developer at start created couple of tables using migration generators and added some columns using migrations. After that, he added table columns straight away using some sql GUI. I was given the sql dump which i imported and set it up on my local machine, now when i created a table using php artisan make:migration create_myTableName_table --create="myTableName" the table migration is created successfully, but, when i did php artisan migrate it's giving me SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'someTable' already exists I checked migrations folder and matched it with current version of someTable and i can see the columns are different, same with other tables aswell.
What should be the best case to handle this in this situation, i want to keep up with Laravel migrations generator so that in future if any other developer want to work on this project he just has to run migration command to migrate database or to create tables or create columns... Should i re-write all migrations ? pleas help. Thanks
Given your situation, I’d put the .sql export in your repository, clear out the old, broken migrations, and create a new one that initially imports the database dump. Then just create migrations as normal going forward.
Quick and dirty?
Delete current migration files. Clear your migrations table and export the whole DB. Put the SQL dump in the repo and instruct other devs to import it before they run php artisan migrate. With the dump imported and migrations table truncated, you can create new migrations with no further collisions with the legacy migrations.
Feeling ambitious?
Use a package like migrations-generator to generate migrations based on your current DB structure. Then, migrate away.
I have created the schema through MySQL Workbench and synchronized it with the database.
All the tables are there in database. Now when I use the
php artisan migrate
command, is there an option to take the fields director from the database instead of specifying the fields name.
Also could you please suggest any other tools on github.
Laravel Migrations Generator will help us generate migration source code from existed database in Laravel 4.
so if you already have your sql schema, created in mysql workbench, then you'd need to put that schema into laravel migrations using the schema builder.
there are tools that make this part easier:
http://www.laravelsd.com/ - kinda like mysql workbench, with an export possibility to laravel migration code
https://github.com/XCMer/larry-four-generator writes existing databases to laravel migration code
Another option is to use our tool Skipper (https://www.skipper18.com) We introduced Laravel support a month ago and now, in a beta phase, it is free for Laraver users.
Skipper allows you to import your MySQL Workbench project directly (or it is possible to import existing database too) and then export migrations and object files from Skipper to your Laravel project.
The benefit of this solution is that you can maintain your ORM schema directly in Skipper and continuously update model object files and create new migrations automatically from the application without the necessity to write any code manually.
If you want to try it, you can download it here https://www.skipper18.com/en/download, and in the initial application license screen select "Laravel Beta license".