Here are the tables in my scenario
user (user_id)
user1_order
user2_order
user3_order
user1_calcs
user2_calcs
..........
I have my own reasons to have separate table per user (lots of data per user, lots of joins/queries in my app, separation of user data, user satisfaction)
Laravel has migration feature, so you have to create a migration that will create a table..
My question is, how would I use Laravel to my scenario? as I am not sure when user signs up, and I can not pre-generate user tables until a user signs up..
Any help is highly appreciated...
You could use Eloquent Events (do not confuse it with Laravel Events) to run table creation tasks, for example you could run custom artisan command directly from your code.
This command could create migrations from prepared stubs and then run php artisan migrate command.
Related
I have a started project in Codeigniter. I thought I will use some part of already created sections of similar site. So I have copied the old database and started work.
On that time it has around 40+ tables and has thousands of rows of data.
Then after I setup my environment for this new project, several tables created and all of those used migrations. It's then setup in development environment, so other team members can also work on.
Now I found old users and lots of data that I copied from old project not required
I decided to remove all tables that is not required for current project.
And need to remove all users and related data that was actually came from old project. Now database has 49 tables and I need only around 10 tables for my current project.
Question is Should I use migration to clear an old database?
Should I use migration to remove thousands of old data that are mixed with development data.
Should I use migration to alter several tables where lots of column not required for my current project?
Please provide suggestions
.. Thanks
In Laravel, migrations are there to keep a track of the structure of the database.
If your old database is not defined in migrations, there is no point to create migrations to remove unused tables. You can clean them manually.
But if you have made migrations for that old DB, then you can create new ones to clean it up.
Anything related to the actual data in the database should be placed within seeders nor custom command (e.g. php artisan make:command CleanData)
The reason is that if you ever need to squash your migrations, you will lose any instructions related to data.
Hello everyone
I'm going to try to explain my problem as clear as possible, feel free to ask me more precision if you didn't understand what I meant and forgive my mistakes, English is not my mother tongue.
My goal
I want to start using migrations again because I need to create a new table, after a year where developers of my company bypassed them by creating/deleting/updating tables directly from phpmyadmin.
The things you have to know
The last migration was a year ago, but many tables have been created without migrations since that time.
Why I need your help
I'd like to know what is the best way to start using again migration without losing data or tables, because I'm working on an environment production.
What is the best way to do that ? Keeping the migrations that already exists and just ignoring the tables that have been created ? Deleting all migration files and deleting all the row in the migration table ?
If I delete all the migration files and truncate the migration table, will a php artisan migratewill have any impact on the existing schema ?
What is the best practice ? Should I recreate all the migrations of all the tables of my schema ? Or should I create only one migration with the new table I want to create ?
You could start from scratch by deleting all migrations and truncating the migrations table.
Then take a look at this post to recreate all the migrations for your current database schema.
Laravel keeps track of the migrations using a dedicated table that records when they were applied. When any one migration gets run, it inserts a new record in the table, and if you roll back a migration the corresponding record is deleted. You can therefore prevent undesired migrations from being run by adding them to this table.
My advice would be as follows:
Create the missing migrations
Run them on your local copy to get the database in the required state there
Export the migrations table
Import it to the production database
If you have any additional migrations you want to run after the ones you ran locally, run them in production
I'd definitely be careful to have a dry run beforehand though - perhaps after exporting the migrations, import the production database to your local copy, then import the migrations, and check it there.
I'd also be inclined to take steps to stop people applying changes to the production database directly - it's a very dangerous step that avoids accountability and makes it hard to test your application locally. Perhaps lock down PHPMyAdmin.
Mostly in these cases I try to sync migrations with my table so that I don't lose the current data which is on the database and I know that my migrations are updated .
So I from the first table whatever you have added in your table manually, you have to add that to your migration too .
In this case in future if you need to create a database truncate or anything else you know that your migrations are already up to date .
To be honest the best practice is to make the changes in your migration not in the database so you have not done the best practice so . this is the best practice that even can be done in your case so you make a migration to your project like this :
php artisan make:migration added_photo_to_user_table --table=users
and then in your migration :
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->text('photo')->nullable;
});
}
then u have to run the command
php artisan migrate
but in your case because you added the fields to the database you don't need to run the last command you just have to make migrations so in future if you want to make update to the database you do it as the best practice and you don't encounter any data lost .
Best way for me to describe my problem and it's go-to solution would be this link;
StackOverflow
My problem is exactly this, and the solution actually is working, but not in my case, either I will have an alternative solution for mine, or I'm doing something wrong with my schema builder and I need to understand it better.
My code is basically like this:
//just an example, not my code
Schema A (as)
//other code, such as table->increments('id')
$table->unsignedInteger('b_id');
$table->unsignedInteger('c_id');
$table->foreign('b_id')->references('id')->on('bs');
$table->foreign('c_id')->references('id')->on('cs');
Schema B (bs)
$table->unsignedInteger('a_id');
$table->unsignedInteger('c_id');
$table->foreign('a_id')->references('id')->on('as');
$table->foreign('c_id')->references('id')->on('cs');
Schema C (cs)
$table->unsignedInteger('a_id');
$table->unsignedInteger('b_id');
$table->foreign('a_id')->references('id')->on('as');
$table->foreign('b_id')->references('id')->on('bs');
So neither order helps me with this solution.
Is there a solution to my case, or my code/schema logic is wrong and I need to modify my code?
Your schema is incorrect. You can't have tables being interdependent, i.e, they can't be both master and slave to each other at the same time. This way, you can never make them at all.
You should create master tables first, let's say A,B,C.
Schema A:
$table->increments('id');
// some other columns
Schema B:
$table->increments('id');
// some other columns
Schema C:
$table->increments('id');
// some other columns
Now, create the child tables, in other words, these are intermediate tables describing many-to-many relationships and you can access them using pivot attribute.
Schema AS:
$table->unsignedInteger('b_id');
$table->unsignedInteger('c_id');
$table->foreign('b_id')->references('id')->on('B');
$table->foreign('c_id')->references('id')->on('C');
Schema BS:
$table->unsignedInteger('a_id');
$table->unsignedInteger('c_id');
$table->foreign('a_id')->references('id')->on('A');
$table->foreign('c_id')->references('id')->on('C');
Schema CS:
$table->unsignedInteger('a_id');
$table->unsignedInteger('b_id');
$table->foreign('a_id')->references('id')->on('A');
$table->foreign('b_id')->references('id')->on('B');
Now, you can successfully run a migration in this order and you should be good to go.
In Laravel >= 5.0, one way to achieve this is to have certain scripts in properly named migration folders. Like I use to have migrations in Sprints.
--migrations/
---Sprint8/
------user_table.php
------car_table.php
--Sprint9/
------complaint_table.php
------supervisor_table.php
With this approach, you have to run the migration command on each of your subfolders:
php artisan migrate --path=/database/migrations/Sprint8
php artisan migrate --path=/database/migrations/Sprint9
However, what you can do is easily extend the artisan system to write your own migrate command that will iterate through all folders under the migrations folder, create these commands for you and run them.
You can also simply write a shell script if you don't want to get into doing this via artisan
To make it clear let's make classic example - User and Post.
Creating db schema in Symfony2 is clean and simple:
we create entities Post and User
additionaly we can simply add columns/indexes to each.
then just add value with OneToMany annotation in User and ManyToOne in Post
..well, that's it. Now if we run db:schema:update --force and we can get what we want - database schema and simple adding another rows in database.
What about Laravel4? So far only solution I found:
create/generate Post and User models
declare in each model which table it refers to
create migrations and in Post migration add foregin key to user_id column
run migration
add in each model methods in which we refer to the other model (hasMany, belongsTo .. )
As I wrote it, it doesn't seem so complicated, but it's not so concentrated in Laravel as it is in Symfony. I'm kinda lazy person and I really enjoy the process in Symfony, while in Laravel it is a little bit too diffuse. Is there any simpler ( lazier :P ) way to do this in Laravel? Something like creating schema based on Model?
The question makes sense but unfortunately there isn't such functionality on Laravel at the moment.
As opposed to running migrations from your models (symfony) you must create the migrations first, the you can use the models to seed database tables if they have foreign keys.
I use the Jeffrey Way Generators https://github.com/JeffreyWay/Laravel-4-Generators
to speed up the process so for example if I have a users table and a profile table (many to many) then I would perform these tasks on command line:
php artisan generate:migration create_users_table --fields="username:string, password:string, email:string"
php artisan generate:migration create_profiles_table --fields="name:string, lastname:string, phone:string"
php artisan migrate
php artisan generate:pivot users profiles
php artisan migrate
Then you can create your models (you can also generate an entire CRUD resource or Scaffold)
php artisan generate:model user
php artisan generate:model profile
Then in your User Model
public function profile()
{
return $this->belongsToMany('Profile');
}
In your Profile Model
public function user()
{
return $this->belongsToMany('User');
}
Yes, there are some plugins / commands that speed up the development.
For example Jeffrey Way's Laravel-4-Generators
I am totally new to FuelPHP, ORM and migrations in general so sorry if I come across like a newbie, but I've been struggling with this for a few hours now so I thought I'd ask for help. I think I'm either doing something wrong or missing something fundamental.
I am trying to create a users model, for simplicity let's say it just has a string representing name.
I was under the impression that using the following two Oil commands would create a users model, and an associated migration which after running would build an associated table:
php oil generate model user name:string
oil refine migrate
This does successfully create the model and migration, but running the second command doesn't build the table in the database.
If I run these commands on the other hand:
php oil generate migration create_user name:text
oil refine migrate
The migration is created and the table is built in my database. I noticed that perpending 'create_' to the migration name made it possible to create the table, whereas leaving it off (i.e php oil generate migration user name:text) doesn't insert the table to the DB. I noticed the generated migrations with and without the 'create_' are significantly different.
So my question ultimately is, how do I create the model, associated migration which creates the table? Or, am I totally misunderstanding something?
Thanks!
If you get 'Already on the latest migration', your migration tracking data is out of sync. Migrations are tracked both in the database (a table called migration) and a config file in your environment folder called migrations.php.
If there is already an entry in one of them, oil will not run it again.
So you can't just delete the table through the backdoor and then run the migration again. You'll have to run a 'migrate:down' to revert the last migration, or if you delete all, also delete the migration table and config file.
Again, credit to Harro Verton on the FuelPHP forums.