I installed entrust on my laravel 5.1. I'm wondering what's the best way to create your first roles?
I see some people creating them with routes but this doesn't seem like a clean way to me. Should I just seed my first roles directly into my database or is there a better way?
In my opinion, this is up to personal preference. As you mentioned already, using a database seeder is a perfectly reasonable solution.
If you really want to contain and separate the code that initializes the roles/permissions, or anything else you need in your application, you can also opt to create a custom Artisan command within Laravel that does the initial setup tasks you need to do. With this method, you can separate your initial production set-up and you can still utilize your database seeders without having to modify them for testing purposes.
Resources:
http://laravel.com/docs/5.1/artisan#writing-commands
https://laracasts.com/lessons/commands-101 (Laravel 4 but still good)
Related
I created a separate integration directory/project (let's call it as project-Interface) in Laravel and I created new DB (let's call it as DB-A) and 3 new tables (table-a,table-b,table-c) through artisan migrate command and models related to that as well in the solution.
Now there is a different project (let's call it as project-Web) in Laravel and it has its own database (let's call it as DB-B) and has its own tables and models created (table-x,table-y,table-z).
I need to do the following:
Can I use DB-B of table-x from project-Interface to save some
details in it?
Can I create the tables table-a,table-b and table-c from project-Interface through migrate command in DB-B?
Can I add some more columns in table-x from project-Interface and use it?
Can I use the existing DB connection of DB-B from the env file of project-Web and use it in env file of Project-Interface?
If yes, will it create a new table in DB-B of project-Web, if I created it from project-Interface? Will the changes reflect there also? Also, if I created new columns in table-x from project-Interface, will that column be reflected in project-Web?
So the purpose here is that the DB should be the same and it should be common wherein it should contain all the tables in it and whatever changes I am making from project-Interface or project-Web it should use the DB-B.
Some answers:
It seems that you are asking if you can write to database B in project A. The short answer is yes, if you can connect to it then you can write to it. The database does not know that you are connecting from a different Laravel project or a project sitting in a different repo - it only understands database users.
You can also run migrations belonging to another project, but based on the information so far, I would advise against this. I will explain more below.
Adding columns to a different database sounds like a restatement of question 2, and my answer would be the same.
The problem you have with mixing migrations is that the second project (project-Web) is not able to create all its tables. This will add complexity to:
creating a new development environment (e.g. when adding a new team member to the project)
creating automated database tests that need to tear down and recreate the database from scratch for every run
creating a new staging/production environment
Given that you want some communication between the two projects, I wonder if an HTTP API would be in order? This will be much easier to manage:
All your tables are stored in one project, and all your logic is stored here too. This will simplify migrations enormously (and thus the creation of all environments I mentioned earlier).
You can offer a web service in one project to offer read/write services to the other project. This is much easier to test from an automation standpoint: in the API project you can run API/HTTP tests, and in the client project, you can use mocks.
This approach will allow you to test the projects in isolation in a clean manner, and then do automated integration testing if you wish (e.g. by deploying both projects to a test server using CI/CD, running the migrations and any seed files, and then running tests on one that causes both projects to work together in the designed fashion).
I have been enjoying working on Laravel for a while now, and am planning to move a fairly large project to Laravel 5.
The new project has fairly large database with numerous tables, and it would take considerable amount of time build migrations, models and controllers individually.
Has anybody worked on this before? What is the best way to go about it?
I have used this great extension to generate migrations as of now - but still for a 200+ tables, it would take quite a long time to do the rest.
Try this one:
https://github.com/reliese/laravel
Reliese Laravel is a collection of Laravel Components which aim is to help the development process of Laravel applications by providing some convenient code-generation capabilities.
How about this: http://packalyst.com/packages/package/ignasbernotas/laravel-model-generator
Model generator Laravel 5 model generator for an existing schema.
It plugs into your existing database and generates model class files
based on the existing tables.
For migrating models and controllers just use artisan commands, you can't get around it any easier than that. For the migrations I can suggest trying to use the following package:
Laravel Database Exporter
It will export your existing DB schemas as Laravel migrations. My suggestion is based on the assumption that you are using MySQL as your RDBMS, because the package I suggested only works with that.
I have a database we use on some of our existing websites, sites were built in Yii framework by another developer so no Laravel, I have set up a new project using laravel but am looking for the best way to link up to that database and return the information.
linking to the database is easy enough, just change the database.php file but I am getting really confused with migrations part and how to call it into a webpage.
So what's the simplest way to go about doing this?
Migrations are used to create or modify database structure. Since you already have a database set up, you don't need to use migrations.
To get accustomed with Laravel I strongly suggest watching:
Laracasts - Laravel 5 Fundamentals
I also suggest you go over the entire Laravel Documentation just to get acquainted with all the framework has to offer.
Our setup is this:
We have and API that feeds an iOS and an Android app
We have an Admin API that feeds an Admin web app
I'm developing the Admin, my colleague is developing the app API.
They both use the same database, and most of the same tables. Merging them into a single project is not an option as we will deploy to Elastic Beanstalk and the Admin doesn't need to scale, since it will be used by a small number of people.
The issue we ran into is handling migrations, and we've arrived to the following conclusions:
We can't both have our own migrations in our projects, as the versions would not add up
If we keep migrations on only one of the projects (we both have access to both projects), the project without migrations can't be redeployed without redeploying the other one
If we make a 3rd project that only has migrations, we are hosting an application that essentially doesn't do anything
While I can think of hacky ways of fixing this issue, we're looking for a best practices approach.
I would recommend the option of creating the third project that only has migrations. That way, you keep all the migrations in one place and avoid problems of inconsistency, and you decouple the migrations from the deployment of either app. The fact that the app doesn't "do" anything shouldn't matter; you don't need to deploy an extra app, just run the migrations from your deployment server. You don't actually have to create a whole Laravel project just for your migrations; it's fairly simple to use Eloquent outside of Laravel. This article gives an example of using the Eloquent query builder to run migrations outside of Laravel. You could also use a lightweight migrations tool like Phinx, which offers a similar feature set to Laravel's built-in migrations but with minimal dependencies.
In the midst of developing a Laravel 4 app, I've decided to start making use of Laravel's Migration feature.
Question: Should we write migrations for creating all the tables that we currently have in the database? Or do we only write migrations for future changes?
There is no complete right answer to this. It all depends on a lot of variables, like your style of development, how many people you're working with and in what kind of environment (single production DB? multiple dev DBs?), what your requirements with migrations are, etc. etc.
If you do decide to write migrations for the entire DB up until this point, you'll need to make sure that your migrations can handle any potential conflicts. Making use of Schema::has() and such to verify tables exist prior to attempting to create them, and such.
Alternatively, you can write migrations as if the DB has a clean slate, and enforce any devs to start with an empty DB prior to running migrations. This has risks, so be careful. Make sure you have backups in case your migration forgot something and you need to modify it.
So, TL;DR: Is using migrations for your entire structure part way through a project necessarily a bad thing? No. Is it right for your application? That entirely depends.