So basically I needed to change the id type of the jobs and failed jobs migrations created by laravel to uuid, but it shows me this error.
SQLSTATE[23502]: Not null violation: 7 ERROR: null value in column \"id\" violates not-null constraint.
I'm using the queue database driver.
I've tried to change the model in the framework files and works somewhat ok, but this is like my critical nuclear solution.
If there is a better and more optimal solution you can think of please go crazy.
Thanks in advance!
The problem is caused by laravel not generating UUID automatically. Normally, if you want a model to use uuid, you override its boot function and provide uuid creation logic. For instance, you can see it in action here:
https://medium.com/binary-cabin/automatically-generating-a-uuid-on-your-laravel-models-b8b9c3599e2b
However, jobs and failed-jobs tables are not models. If you inspect Illuminate/Queue/DatabaseQueue class, you will see that it just do basic DB updates, inserts. So if you really have to change these tables to use UUID, only option you have is to refactor this core laravel code which is not suggested.
Another approach you can take is, create 2 new intermediate models (e.g. MyJob and MyFailedJob) for jobs and failed jobs, and with sql triggers on original table populate these table. You can use uuid on these intermediate models.
Hope it helps
Related
if not,there will be an error:
Column 'xxxx' doesn't make part of the column map
i can't find any information to solve this problem
You have two options:
You can update array with column map in method columnMap() to include changes in database table column names.
You can remove the method columnMap() from Model class - this will disable checking if columns exist in database table, allowing You to ignore newly added fields. Changes to existing table columns can break existing code.
If You have control over the database schema, then use the first method, as this will prevent errors like only some of the database queries not working. Otherwise use the second method.
Here is a helpful link to Phalcon documentation on column mapping.
Phalcon comes with devtools which is a great command line tool to automate tasks like creating models and controllers. I'd recommend that you install this and generate model using command like phalcon model MODELNAME. Otherwise, you will have to manually change the model names in the columnmap located in the model class.
I'm learning laravel 5 and it's relationship with databases. I can find tons of info regarding how to work with sqlite and mysql but I'm having problems understanding what migrations are, how they are related with databases and my main issue...
If I have a pre-created postgres database with, let's say, 10 tables and their relationships already up and running, how can I make Laravel interact with them?
For example, I have my postgres schema table defined like this:
CREATE TABLE "users" (
"id" integer NOT NULL DEFAULT nextval('users_seq'),
"name" character varying(30) NOT NULL,
"email" character varying(50) NOT NULL UNIQUE,
"password" character varying(120) NOT NULL UNIQUE,
CONSTRAINT users_pk PRIMARY KEY ("id")
) WITH (
OIDS=FALSE
);
I already know Laravel comes with a generic migration for users table but how exactly should I work from within Laravel connecting to my db?
By the way, my database's name would be dummy.
May I use something like a migration class?
But as far as I understand, migrations are for creating/deleting/etc tables, right?
Or should I directly create a controller to interact with de db like these?
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Http\Requests;
class PagesController extends Controller
{
public function index()
{
$users = DB::table('users')->get();
return view('DBHandler',compact('users'));
}
}
And I imagine this is the query builder way of doing things and eloquent's way is quite different.
Any help would be appreciated.
According to Documentation of Laravel:
Migrations are like version control for your database, allowing a team to easily modify and share the application's database schema. Migrations are typically paired with Laravel's schema builder to easily build your application's database schema.
If you have a team working with you, is highly recommendable to use them for changes that must be applied on the scheme to the application works, these migrations let you to apply changes to database like drop, create, update, etc. On the other hand if you're going to start developing with a Schema already created, there is no problem you can interact with your scheme with Eloquent.
The way as Laravel take information from your database is with Eloquent a ORM, Here is the introduction from Laravel Documentation:
The Eloquent ORM included with Laravel provides a beautiful, simple ActiveRecord implementation for working with your database. Each database table has a corresponding "Model" which is used to interact with that table. Models allow you to query for data in your tables, as well as insert new records into the table.
So you have to create a Model for each one of your tables, except tables many to many. If your table is Users you must name the model User and Eloquent take it automatically if not, you must overwrite the $table attribute at the model like this:
public $table = 'user';
The rest what you can do with Eloquent you can find it at the documentation here
I hope this helps you out.
From the blog laravelbooks.com, quoting:
[...] Migrations are the Laravel way of helping you to evolve the database schema of your application (also known as its DDL) without having to drop and re-create the database each time you make a change. And not having to drop and recreate the database each time a change happens means that you don’t lose your development data. The only changes made when you execute a migration are those necessary to move the schema from one version to another, whether that move is forward or backward in time.
Not only does Laravel migration provide you with a means to change your database schema in an iterative manner, but it lets you do so using PHP code, rather than SQL! The Laravel Schema Builder allows us to create database tables and insert columns or indices quickly. It uses clean and expressive syntax to make database operations happen. You may think of Laravel migration as version control for your databases! [...]
There I found a more explanatory way to laravel than the official documentation, though the later it's also good
So as title pretty much describes, I'm trying to utilize phinx for database migration, but I have AUTO-INCREMENT column, which is not used as the primary key. As far as I see, this can't be done with phinx.
I realize, that I could probably do without that column altogether, but it's the part of the huge legacy code and, at the moment at least, I don't have the time to refactor entire app to ensure that column is not used anywhere. If my conclusion is correct and phinx is not able to achieve this, I'd appreciate some alternatives, possessing described functionality
You can use the up and down phinx method to create this table using execute fontion with pure sql.
See this
I have a migration called CreateItemsTable; I ran that, I have items in that table, now I need to add a new field to the table. I can't just add a field to the migration file and migrate:refresh because I need the data that's in it.
Am I supposed to make another migration for adding a field? That's seems like mess while I'm testing things in development, I might change fields a lot. I'm not sure if migrations are cleaner than just PhpMyAdmin... or maybe I don't understand them?
Yes, each time you need to change a table in some way you'd create a new migration for it. That's the whole point of migrations. When you're developing in a collaborative environment and you pull down some changes from a remote repository, one of the things you should do (if working with a database) is run any migrations that other developers might have created. This keeps your databases in sync.
Sure you might drop and add columns occasionally but it's no big deal.
When you create a table for the first time you are probably using Schema::create(). All subsequent migrations for that table should use Scheme::table(). It accepts the same parameters except it doesn't attempt to create the table first.
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.