Editing carrier details creates a new id_carrier and deletes the old one

[30knees]

I edited the price of two carriers and the id_carrier got changed and the old one deleted.

Specifically:

idcarrier 20 got replaced with idcarrier 29 idcarrier 21 got replaced with idcarrier 30 and then id_carrier 30 got replaced with 31

This messes up modules that rely on the id_carrier and assume it stays stable.

[30knees]

p.s. Is there a query I can run to eg replace everywhere in the database, so tbcart and tborders and tborderdetail and anywhere else id_carrier 31 with 22?

[Traumflug]

This behavior might be by design. The idea is probably that older orders are related to the older version of the carrier, while newer orders get the newer one.

The obvious assumption is that carriers don't change. Accordingly one has to set up carriers first, then configure these modules.

Can you give us an idea on why these carriers need changing?

[30knees]

@traumflug For example if one wants to adjust the shipping price, the weight ranges, etc. There is no reason why changing the shipping price should affect the carrier id.

[lesley]

There is, for historic purposes.

[30knees]

@lesley I strongly disagree, especially considering that it prevents modules from relying on an unchanging id_carrier.

What historic purposes are there? All old prices can be kept in the old orders, for example.

[Traumflug]

All old prices can be kept in the old orders, for example.

Yes, this is one way of archiving history. The other one is to just store reference pointers, along with the unchanged reference its self. That's a design decision software developers have to do. Both approaches have advantages and disadvantages.

Prestashop took the choice to keep unchanged references. If some modules chokes on this I'd say they're simply not Prestashop or thirty bees compatible.

[lesley]

Case in point of how it was useful to me last week. I set up carriers on a site using a rate table 2 years ago. The guy calls me complaining about them not working correctly. Basically they were letting Canada orders through at US prices. He blamed me of course. So I checked everything and they were in fact broken. Then I looked at the database and I could tell they had been edited, because right when the issue started happening new carrier IDs were assigned to orders. So I knew it was not my fault and I charged him.

There are lots of other uses as well, but there is a real world use.

[30knees]

Hmm, I can't comment, but it sounds like an edge case to me and one that bloats the database. Is the decision then not to change the logic?

[lesley]

It cannot be changed, it would break a lot of things. We are literally talking about .5 kb of data, its not going to bloat the database that much.