larastan: Larastan doesn't detect a renameColumn name

Larastan Version: v2.9.4
Laravel Version: v10.48.7
Level: 1

Description

In a migration, I create a column last_changed_at, and in a later migration I do a $table->renameColumn('last_changed_at', 'first_detection_at'). last_changed_at isn’t used anymore, but first_detection_at is.

But phpstan gives me an error:

Access to an undefined property App\Models\SiteCheck::$first_detection_at.

Only that property. All the others are detected OK. It seems the renameColumn() doesn’t work.

If I edit the migration and add in up():

// larastan
return;
\Schema::table('site_checks', function(Blueprint $table) {
	$table->timestamp('first_detection_at');
});

Larastan gets it. But that’s too hacky, even for me.

If I add some debug in SchemaAggregator:

case 'renamecolumn':
	dump($columnName, $secondArg->value);

and run phpstan with --debug, it seems Larastan does understand the renameColumn():

"last_changed_at" // vendor/larastan/larastan/src/Properties/SchemaAggregator.php:412
"first_detection_at" // vendor/larastan/larastan/src/Properties/SchemaAggregator.php:412

but it still doesn’t apply the change…?

Should I read the migrations as bootstrap files or something?

~~I’ll try to upgrade Laravel and Larastan to try the newest version.~~ Same error with newest versions.

About this issue

Original URL
State: closed
Created 2 months ago
Comments: 16 (4 by maintainers)

Most upvoted comments

Is that the level?

Yes, level 1 doesn’t complain. Level 2 does. Alright, I’m really done here now 😆 Thanks guys.

rudiedirkx on Apr 16, 2024

Waaaaaaaaaaaaaaaait!!

"UNRENAMABLE: last_changed_at" // vendor/larastan/larastan/src/Properties/SchemaTable.php:31

    public function renameColumn(string $oldName, string $newName): void
    {
        if (! isset($this->columns[$oldName])) {
dump("UNRENAMABLE: $oldName");
            return;
        }

Larastan doesn’t even think the original column last_changed_at exists. And that totally makes sense, because I’m an idiot!

An earlier migration created last_changed_at, but not using Schema/Blueprint:

		\DB::statement("
			alter table site_checks
			drop started_at,
			change finished_at last_changed_at int unsigned not null,
			add remote int unsigned not null default 0
		");

Sorry for wasting your time guys. That was not mysterious at all.

Maybe SchemaTable::renameColumn() could throw a warning or something 😆 so dumb people don’t get confused for days.

Thanks for bearing with me. I’ll make better migrations in the future ❤️

rudiedirkx on Apr 16, 2024

After this line you can put a dd($this->tables) to see everything Larastan recognized.

There’s no first_detection_at column! Yet, in other places (outside $this context), there’s no error for this property, so sometimes it does exist… Computers are weird.

                        case 'dropcolumn':
                        case 'dropifexists':
                        case 'dropsoftdeletes':
                        case 'dropsoftdeletestz':
                        case 'removecolumn':
                        case 'drop':
dump($columnName);

never triggers for first_detection_at, so it doesn’t think it’s deleted after being renamed.

I give up.

rudiedirkx on Apr 16, 2024

Try to clear the phpstan cache

I do that often. And in this case in run with --debug, so no cache.

Is there a way to debug model properties? Or do they only resolve during analysis? I don’t understand how larastan sees and evals the renameColumn, but still doesn’t know the new property. Can I see a list of properties it finds or something?

After this line you can put a dd($this->tables) to see everything Larastan recognized.

canvural on Apr 16, 2024

Hi,

We’d need more information. Or even better a small repository that can reproduce the issue. As you can see, we cannot reproduce it.

canvural on Apr 16, 2024