Laravel-activitylog: subject_id is NULL on Created

[ngkarkeong]

For those who may have any idea,

For some reason, the subject_id is null on the subject creation Event.

I did make such customization changed though.

• subject_id changed to varchar type on activity_log table.
• on the subject model, I use 'Code' instead of laravel convention 'id' as the primary key
  beside the primary key is fillable instead of auto increment.
  can those changed affect the logging behavior?

thanks for helping

[Gummibeer]

Have you changed the primary key name? We only use laravel core logic $activity->subject()->associate($subject). So if you've adjusted these things following the laravel way it should work. But if you've changed the type from int to varchar - I assume you use some kind of string UID? If so: have you changed the type of the subject_id column as well?

[ngkarkeong]

Yes, that was what I thought.
under the model, I did added protected $primaryKey = 'Code'; to specify the primary key for the model for UID.
andi make this change as well $table->string('subject_id')->nullable(); in migration script to string instead of int.

The situation is,
on updated event the subject_id get the primary key just fine
but the problem is, on created event the subject_id get a NULL.

[Gummibeer]

When and how is your primary key filled? Could it be that it simply doesn't exist because the callback that adds the ID runs after our activity one? 🤔

[ngkarkeong]

I am not sure i understand the question correctly. I do pass in the primary key at the same time i pass in all the other parameters in model upon the model creation.

Campaign::create($data);

$data included the primary key and other data using Laravel default static create function.
In this case, the subject_id will get a NULL.

however

I do found when I implementing ActivityLog on another model, this model with the auto increment ID as a primary key. it works correctly, the subject_id filled with the model primary key without a problem.

could self-fill primary key effect that?

[Gummibeer]

Ok, you answered my question. Could also be that you fill it with an model event listener.
I'm not sure how Laravel handles this internal. You should debug the associate() method and find out what's called internal and where your ID get's "lost".

[ngkarkeong]

I think I found the cause of this. laravel will only get the last insert id upon save().and it have to be auto increment primary key base on LAST_INSERT_ID from SQL. Hence by using UUID, there is no auto increment as last insert id, so that will return a NULL instead.

https://laracasts.com/discuss/channels/eloquent/eloquent-does-not-able-to-catch-custom-primary-key-after-save-created-by-mysql-trigger

Perhaps, this can consider an enhancement for the future?

[Gummibeer]

I would say that this is something that should be fixed in eloquent and not this package!? We only build on top of eloquent logic.

[ngkarkeong]

I am not experienced enough to tell where should include the code. but if you are me, how would you suggest to improve the open source code? never work on it, but would love to contribute to open source.

[Gummibeer]

First of all, if not already done, I would search for or open an issue in the eloquent package.
If there is already a blog post I bet that there are also issues related to it.
If there are and they are closed find out why and if it's an "we will never fix it".
If so try to find already created polyfills and if they work and you can integrate them.

If they want to fix it but it's not done you will have a hard time because:

1. it's not important enough and that's why no experienced developer tried to solve it
2. experienced developers tried to solve it but didn't find a way

But the super first thing you could do would be to add a failing unittest for this issue. This would allow all of us to work on the same base to fix it. Could be that there is an easy fix that we could integrate on our side.

https://help.github.com/en/articles/about-pull-requests

[JoseRoot]

Hi I had a similar problem on activitylog 3.2 and laravel 5.7.
I was using a varchar "id" and the subject_id was getting filled with 0 on created even though I changed the subject type to varchar on the migration file.

My model was looking like this:

class Collaborator extends Model
{
    use LogsActivity;

    protected $keyType = 'string';
    protected $table = 'collaborators';
    protected static $logAttributes =  ...
    protected static $logOnlyDirty = true;
    //  ....

I didn't know what to do so I added

public $incrementing = false;

And guess what... I started to get the correct subject_id value on my log table

[TutanRamon]

Hi I had a similar problem on activitylog 3.2 and laravel 5.7.
I was using a varchar "id" and the subject_id was getting filled with 0 on created even though I changed the subject type to varchar on the migration file.

My model was looking like this:

class Collaborator extends Model
{
    use LogsActivity;

    protected $keyType = 'string';
    protected $table = 'collaborators';
    protected static $logAttributes =  ...
    protected static $logOnlyDirty = true;
    //  ....

I didn't know what to do so I added

public $incrementing = false;

And guess what... I started to get the correct subject_id value on my log table

I can confirm this behaviour. I am running the latest Laravel (8.7.1) and have a custom primary key on some of my models. On updating and deleting, ActivityLog reports the right value for the primary key. However, when a model is created, I see the 'id' value being used instead my custom primary key.

But with the solution mentioned above (public $incrementing = false;) the problem is solved. Thanks!