Problem with Laravel spatie/laravel-permissions ( HasRole in Model User ) - php

I have a problem with the spatie/laravel-permissions library.
Previously I had it implemented in my system but after doing composer update it stopped working...
The problem is when I add the HasRole in my User model. Everything crashes and I get the error:
"Call to a member function first() on array "
Making mention of the PermissionRegistrar package file.
Likewise, if I try to enter another route in my system, the error that appears is "
Undefined index: name"
It should be noted that I have my model created, my tables in the database and I carry out the package installation process following the documentation, and as I said before, the roles and permissions system worked for me before.
Something I should mention is that I had previously replaced the "name" field with "description" but I had some configuration problems with the library so I ran another migration adding the Name field, which the library requires. After running the migration, everything seemed to work correctly

You probably have a cache issue specifically related to Spatie. If you face any kind of issues when you are seeding your DB, you can add this line at the top of your seed within the run() method
app()[\Spatie\Permission\PermissionRegistrar::class]->forgetCachedPermissions();
On the other hand, if you changed something manually, let's say from DB, you can try with artisan command
php artisan permission:cache-reset
https://spatie.be/docs/laravel-permission/v5/basic-usage/artisan#content-resetting-the-cache
Note that you need to clear cache even if you are running a fresh install by using
php artisan migrate:fresh --seed

So you just ran a full update of all packages?
That is kind of a scary situation, I don't think I've ever done a full update to all packages.
I'm not sure what version of spatie you are coming or going with, that might help.
When I did a full update from Laravel 5.7 all the way to Laravel 8, spatie was a pain. Not just a little pain but a full on work for 4 days updating pain. All the database tables were renamed, more added. Then I had to write code to transfer 20k users and permissions over from the old tables to the new tables with correct relationships. Then I had to go though and use the newer functions...etc. Nightmare.
So as you can see you are a little vague in your question for a proper answer.

Related

CakePHP Migrations Path and Migration Table Name?

This is my first time dealing with anything related to CakePHP. I'm attempting to use CakePHP Migrations to handle version control for future database updates, and there are three different configuration options that I've been trying to track down but haven't been able to find.
How do you change the name of the table that CakePHP creates to track applied migrations?
How do you change the path that migration files are stored in?
How do you change the path that seeds are stored in?
I've found all of those options for the instance of Phinx that CakePHP Migrations uses, but changing them doesn't seem to affect anything. Is it even possible to change these things? Thanks for the help!
bin\cake migrations help migrate
You will see "-s, --source=SOURCE The folder where migrations are in". Same thing for the seeding.

Laravel 4 migrate:make not working; just stops after "Compiling views" step

I'm a total newbie following the guestbook tutorial at laravelbook.com, via Koding.com.
In my project directory, running php artisan migrate:make create_entries_table (also tried with --create=entries appended) produces the following response:
Generated migration: blah_blah_blah_create_entries_table
Compiling common classes
Compiling views
That's it. No migration table or file is created. Any idea as to why this is happening? I already asked on the L forum yesterday, nobody's responded :( Would really appreciate some insight on this...
UPDATE:
Very odd. I ran migrate:reset, and it said Nothing to rollback. But now two migration files are there, from yesterday (one with schema blueprint, one just with blank up & down functions)! No rows in migrations table though.
Other than the migration files not appearing, this is expected behaviour. The migrate:make command only creates the migration file in which you will specify what database actions Laravel is supposed to trigger when migrating (up) or rolling back (down). By default that file will contain a class (which is named by studly-casing the migration name) which up and down methods, nothing more. You might want to use Laravel's Schema class, as per usual, or you might want to do raw queries using the DB class, but you're actually free to put whatever code you want to automate in there (I sometimes run artisan commands in my migrations). Since no error is triggered, I'm assuming Laravel has permission to create files in your database/migrations folder, so it might just be that your app is not refreshing the files view afterwards?
Anyway, in order to actually run the migrations, which will create the migrations table in your database if there isn't one already, is just php artisan migrate. To rollback the last batch of migrations you can use php artisan migrate:rollback and to rollback all batches you use php artisan migrate:reset, but either command is useless if no migration table yet exists, which appeared to be your case.

laravel 4 - change column type with migration generator?

I am trying to create all files related to the table/db migration throughout the CMD with laravel generators and other tools.
And i am looking for to change column type with cmd line similar to this one:
$ php artisan generate:migration add_username_to_users_table
--fields="username:string"
i use this one to add username field - i believe its from the generator build for laravel 4. so i wonder if there is similar command in order to change column type to integer.
if someone have spread cheat with all the possible commends that would be great - thanks!
As you know, the Artisan CLI will create a migration file and if you notice, the file's name will be something like 2014_05_12_200322_create_users_table.php, which is the date and time of creation. If you run the command again with a changed column type, it will just create a new migration file for you.
This is a good thing and is something desired because otherwise it could get quite confusing keeping track of something that has been run or changed, especially when working in working in a team. So, use the rollback command and change your migration file as per your requirements and run the migration again.
migrate:rollback
Edit: Here's an article you should check out.
Have a look at Jeffrey Way's Migrations Generator
https://github.com/JeffreyWay/Laravel-4-Generators#migrations
extends migrations with many handy tools, including what you are looking for

Creating migrations in Laravel 4 for an existing DB

I'm about to start building an API for an existing app with the DB already in production. Functionality will slowly be ported to the API in the future and the app will become more "API-centric".
One of the main starting points is to adopt migrations and a build process. I have reservations on the best way to create migrations for an existing schema without breaking production when they are executed.
As we would like to move quickly with porting functionality over to the API, we ideally want to recreate our current schema as part of our build process and get some core unit tests in place - as opposed to just creating migrations for future changes.
This is where I become unsure as to the best place to start.
What is the best approach for a task like this?
Could the current schema be imported as our first migration?
Could this initial migration be wrapped in something like:
if ( App::environment() !== 'production' ) to ensure it isn't executed in a production environment?
Is it ok to exclude a migration for a particular environment or could this cause problems?
Is there maybe another approach or something stupidly simple I'm missing? :)
I created a tool not to long ago that will generate all the migrations for your current database schema. It also adds the newly created migrations to the migrations table, as the tables already exist. You can get it here: https://github.com/Xethron/migrations-generator
Secondly, I use the following line of code in my DatabaseSeeder, but you can add it to any function you wish to disable in production:
if (App::environment() === 'production') {
exit('Don\'t be stupid, this is a production server!!!');
}
It shouldn't be a problem if you stop execution by throwing an error or as I do above. If you don't, Laravel will believe the changes happened successfully and remove them from the migrations table, and cause errors when running your migrations. The only exception is if you exclude both the up and down code (But I can't see why you would want to do that)
Hope this helps.
I wouldn't suggest running migrations in production environment at all, but if you must then make a backup copy of the database first and also create a copy of the database locally and do the migration there then test to make sure it all works properly.
You could create your first migration and manually add all the schema layout to it. But I would actually do this in a few migrations to have each table as its own migration.
Since migrations are run from the CLI using artisan you can pass the environment and the database you want the migration to be run on:
artisan migrate --database="connectionName" --env="local"
There is no issue running migration on a particular environment besides what I stated above for production.
Remember to add all existing schema layouts from step 1 (the migration file name excluding the extension e.g. 2014_03_25_143340_AddCountriesTable) to the migrations table in the database, otherwise running the command in step 2 will throw errors about table already exist.
Hope this helps.

Generating migration from existing database in Yii or Laravel

I'm working on a project that has a fairly complex database (150+ tables). In order to be able to maintain changes, I've decided to add migrations, preferably using Yii or Laravel.
Does anybody know, if it is possible to generate a initial migration from an existing database?
Creating it by hand would:
take for ever and
be very error-prone.
If there is no way, does anybody know a good PHP-based framework, that supports such functionality?
Instructions for accomplishing this in Yii:
Add your database connection settings to protected/config/console.php.
Run yiic migrate create initial to create the stub code for the migration.
Copy contents of this gist to protected/commands/InitialDbMigrationCommand.php.
Run yiic initialdbmigration 'name_of_your_database' > initial_migration.php to generate up() and down() methods for initial database migration.
Copy and paste up() and down() methods from initial_migration.php to the file created in the protected/migrations folder in step 2.
'Doctrine Project' (aka Doctrine) has the ability to create DB migrations for existing DB structures, so you can recreate the existing structure. It can be easily implemented in Symfony, Laravel, also in Yii and many frameworks.
Sample from:
http://symfony.com/legacy/doc/doctrine/1_2/en/07-Migrations
From Database
If you have an existing database you can build a set of migration
classes that will re-create your database by running the following
command.
$ ./symfony doctrine:generate-migrations-db
From Models
If you have an existing set of models you can build a set of migration
classes that will create your database by running the following
command.
$ ./symfony doctrine:generate-migrations-models
Here is a Laravel package I created that does exactly that. It automatically generates clean and accurate Laravel migrations from your existing database.
As it doesn't make any assumptions of the database, it should work on any database structure while even keeping the original index and foreign key names.
https://github.com/Xethron/migrations-generator
Well since migration is about setting up your database structure and make changes to it, not to reflect a current database there is no such way.
And this is also not a step you have to make. You can start from where you are at the moment, which will make you able to rollback up to this point. Which means you can make migrations for your current tables without having to specify their entire structure, but just the changes only.
Let's say you have a table called user and want to add their firstname to it.
php artisan migrate:make add_firstname_to_user
Now go into application/migrations and find the migration file, add this
public function up()
{
Schema::table('user', function($table)
{
$table->string('firstname');
});
}
public function down() {
Schema::table('user', function($table)
{
$table->drop_column('firstname');
});
}
Now you can add migrate it
php artisan migrate:install // if you haven't run this, should only be once
php artisan migrate
.. and rollback using
php artisan migrate:rollback
This will add or drop the column firstname, without affecting your table in any other way.
As for Yii 1.x, schmunk has created a wonderful database-command yiic command.
This command covers only up migrations. You must write your own down migrations.
To use it:
Get the newest version from GitHub and put it's contents into /protected/commands folder (create one, if it does not exist). Note, that you need to put contents as is (without subfolder for this particular command), which is contrary to what we do for example for extensions.
Rename EDatabaseCommand.php file (and class inside) to DatabaseCommand.php, if you want to use yiic database command (as suggested in docs). Without this fix, you'll have to use yiic edatabase command, as there's slight inconsistency between docs and the code (at least in the newest version, as of writing this; maybe schmunk is going to fix this).
Having this, navigate back to protected folder in your console and execute yiic database dump migration_name --prefix=table_name.
This will create a migration protected/runtime/migration_name.php file with proper date and time in the beginning of file name, filled with series of CDbMigration commands to recreate your database schema. Visit "Usage" section in the docs to read more about customizing command.
I think that the answer is: https://github.com/jamband/yii2-schemadump for Yii2
"This command to generate the schema from an existing database."
I use both Yii and Laravel and I could not find what you require for either of them. They both create empty files and you need to create the migration script yourself.
For a table of 150 tables it will be challenge to create the migrations yourself, but it is not quite as hard as you imagine. Because you already have the information on the fields it should not take so long to create.
After doing some research, here's what you're going to need for Laravel: https://github.com/XCMer/larry-four-generator
(version 4 at least, who knows how long this will work, Laravel changes too fast and has too many breaking changes)
You'll want to run php artisan larry:fromdb and it'll show you the tables...You can also exclude or only process certain tables (look at the readme).
Again, super super useful if you like to build your schema in something like MySQL Workbench. I also saw mention of a package that would parse the workbench files...But the link was dead.
You may also wish to use this larry package with: https://github.com/JeffreyWay/Laravel-4-Generators
You can then create scaffolding a la CakePHP style.
Alternatively, try this package: https://github.com/barryvdh/laravel-migration-generator
There is one now for Yii:
This allows a distributed team to easily update the db locally and then distribute it's updates with thee other developers automatically with the rest of the code via a versioning control system (I used git). It also performs a full initial db dump to xml and to a migration file.
project home:
https://code.google.com/p/yii-automatically-generated-migration-files/
source code:
https://code.google.com/p/yii-automatically-generated-migration-files/source/checkout
I've created it from scratch as I was annoyed with the fact that I had to do this manually in order to distribute it to my team.
Hope it helps!
Feel free to share bugs, improvements and comments.

Categories