Skip to content

Conversation

@Jade-GG
Copy link
Collaborator

@Jade-GG Jade-GG commented Jan 27, 2026

This is needed for rapidez/statamic where we want to use sku as a primary key (to make sure products always stay attached even after a product re-import which may affect entity ids)

ref: RAP-1727

@royduin
Copy link
Member

royduin commented Jan 28, 2026

@Jade-GG
Copy link
Collaborator Author

Jade-GG commented Jan 28, 2026

Not really, no. When you use getKeyName() you will (of course) get the primary key as defined by the model which we purposefully set to sku: https://github.com/rapidez/statamic/blob/master/src/Models/Product.php#L21

We need both the SKU to be primary key and entity_id for the attribute relation at the same time, so we need to have both. Only way to do that would be to no longer assume that the primary key is always used for that, and instead use a separate variable for that.

  • No impact on performance?

Not any that I could tell, especially given that this will only affect the booting part of the model very slightly.

Obviously, if you're using a key that's not indexed it will be slower. However that's not really our problem, and this PR won't really affect that. In this specific case for rapidez/statamic, the SKU field is actually indexed anyway.

Copy link
Member

@indykoning indykoning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't setting the primary key to sku impact more relationships?
Or is it only these that utilise $this->primaryKey for that?

@Jade-GG
Copy link
Collaborator Author

Jade-GG commented Jan 28, 2026

Wouldn't setting the primary key to sku impact more relationships? Or is it only these that utilise $this->primaryKey for that?

Hm, looks like about half of the relations on the product model right now have the entity_id mentioned explicitly. This means relations like tierPrices and reviews will work correctly, but options and reviewSummary will not.

Now I'm not sure if this is the ideal approach. However, I don't know if there's any other way to make this work properly 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants