I'm learning laravel and in most of tutorials they are making migrations using artisan.
I skip that step and I'm working directly on a database.
I don't know for what can a migration be useful.
so the question is: what is exactly a migration?
If you are the lone developer, you may not get much use out of it.
But imagine you have multiple developers each with your app stored locally on their machine. What happens when you need to make an update to the database? You would have to make the update, send the query to each other developer, and they would have to run the query on their machines. Once you get a decent amount of developers making changes to the database, this process can quickly become overwhelming and it's only a matter of time before people start missing the changes.
With migrations, all of the changes are stored as files, so in order for a developer to catch up, all they need to do is fetch the code changes and run php artisan migrate and all the work is done for them. This means all your developers are consistently working with the same database structure.
Related
What is a neat way to recreate heroku dataclips on my local machine so that I have immediate access to the same useful queries locally which I do on an instance of my app on heroku?
I'm referring to the ability to query the state of the local database one is working with during application development, i.e. testing data, if you like (though of course after I pg:pull it's simply a copy of production data for testing purposes).
I have found I have come to rely on the views the dataclips give me into production data, which then assists in the courage to not allow primitive readability of bare tables to be a significant design consideration when adding to or adjusting my database schema. That means I can pursue more normalisation with confidence which can be wonderfully freeing.
So, I just realised this morning that this could be really quite useful, so, lets consider it two steps:
A high level overview of the concepts involved.
Details of how to do it, with some examples.
So to start with, do heroku dataclips correspond directly (postgres) database views?
Heroku Dataclips does nothing more than execute a given query and display/visualize the resulting data set. Additionally, dataclips are only able to query against Heroku Postgres databases. Simply put, there's no way to target a local database with the heroku dataclip tooling.
You could potentially create a Heroku Postgres database with the express purpose to model the state of your local development database and use that. For instance, every time you'd like to run a dataclip against your local instance you'd push the data up to this purposed database and then execute the dataclip against that database. It's an extra step but if you need to use Dataclips it's likely the only reasonable way to do it for the purposes you've expressed here.
We are looking to implement Continuous Integration using Circle CI but we are not sure on how should we proceed with our test database. We have the following alternatives in mind:
Run the migrations from scratch (the problem is that we have a lot of migration files, our first migrations were moving everything from MySQL and PostgreSQL and using a legacy database, so, it's rather complex).
Recreate the current DB and have a .sql file that will create our current tables, and then, we create a seeder to fill the information that we need.
But we are not sure which is the best alternative or if we're missing something?
Thank you
I have been working with Laravel for about a couple of months now - loving it. Have a question about the workflow that is recommended for managing changes to the database.
I have a test database that I used to develop my app, and when I was reasonably happy, I created a production database by copying the structure in phpMyAdmin. I had built the initial database on phpMyAdmin, as I was not familiar with the Laravel Migrations.
Now I am at a point where I better understand the power of Laravel Migrations, and would like to use them going forward to update the test database and move those changes to the production.
What is the course of action for me? Can I delete everything in the app/database/migrations dir and start from scratch? Will there be issues down the line calling php artisan migrate in my test and production environment?
Thanks in advance for the responses!
Short answer: no problems. If you just add/alter/remove tables/columns in the up() and down() methods.
Longer answer: still no problem. As long as you don't drop a table that is not created in an up() method.
But let's say you get to work with another developer, that person also wants to develop on a local DB. But you don't have the migration for it - so the new dev needs to run the initial structure from test DB, and then apply the new migrations.
In that case I would start with 1 big migration where you create all the initial tables, and in the down() the drops of those tables, so the new dev can just run the migrate and start coding.
edit: and after that migration for the initial structure, just add new ones while developing ;)
I am new to using Laravel, and I'm currently learning about Laravel's database migration and seeding features.
It's working with the command prompt, but I can migrate and seed in phpMyAdmin as well. What are the advantages and disadvantages of migrating and seeding within Laravel as opposed to phpMyAdmin?
From Laravel docs on Migrations & Seeding:
Migrations are a type of version control for your database. They allow a team to modify the database schema and stay up to date on the current schema state.
A simple search for why database migration also gives me some pretty decent results. One of the easiest to understand is a page by FlywayDB (I have no idea who they are until I search this term up):
Database migrations are a great way to regain control of this mess. They allow you to:
Recreate a database from scratch
Make it clear at all times what state a database is in
Migrate in a deterministic way from your current version of the database to a newer one
The illustration they made perhaps explain it more clearly, so you may want to check it out.
Hey guys,
I need to figure out a way to back up and also migrate our Oracle database from our production schema to the dev schema and the other way around.
We have bunch of config tables that drive how systems on our platform run, and when setting up new systems or doing maintenance, we need to update our config tables. We want to be able to work on the dev schemas and after setting up a system/feature, we want to be able to migrate all those configs to the dev schemas.
I thought of running a procedure where we give the ID of the system (from the main table) and i would go through all the tables and select nvl(..) and if it doesn't exist, i would insert into, and if it does exist then i just run an update on that row.
This code will get very messy and complicated especially since the whole config schema is very complex and it might be hard to handle all the keys properly.
Another option i was looking at was triggers, so when setting up a new system, there would be a log of all the statements we ran while setting up/editing a system, then we would run it on our production schema.
I'm on a coop term, and have only been working with databases for 6 months, so i don't know that much and any information/advice would be greatly appericiated.
(We use pl/sql)
What about using export / import (or datapump) to bring over the config tables?
Check out data comparison tools like this
Think TOAD has one built in. I'm sure there are others out there too.
It is common to have tables in a schema that are what we call "static data", i.e. the users don't change it because it controls how the application works.
Each change to config data should not be run ad-hoc in the target environment. Instead, you design and code your DML carefully in one or more scripts, which get tested in a dev environment, checked into change control, and can be re-run in any environment when required.