Update database after the last update on dev

[pokoli (Sergi Almacellas Abellana)]

@nicoe

Of course the issue is that previously people did not use the code as the SKU, we would need to find something to solve this for them.

Maybe we can add a warning and a query to update the codes to make then unique. Something like:

update product_product set code = CONCAT(code, CONCAT('-', CAST(id as varchar))) where COALESCE(code, '') != '';

This is the easiest solution to solve de problem.

[risto3]

don’t change the codes that have been created for a reason (read: business use)

[pokoli (Sergi Almacellas Abellana)]

The code usage won’t be changed as we use the starting part when searching on codes. So if you have the code 123 duplicated, searching for this code will also return the same results after appling the query.

This will allow yo to add the constraint and also includes a separator (’-’) to be able to keep the original code if required.

This allows each company to fix the codes in a single maner depending on their business use. As we support all business we can not provide a single solution for all cases.

You have to look deper to see the light on the tunnel

[yangoon (Mathias Behrle)]

@pokoli

The code usage won’t be changed as we use the starting part when searching on codes. So if you have the code 123 duplicated, searching for this code will also return the same results after appling the query.

The code usage is changed. If there is an implementation that searches for code ‘=’, not code ‘ilke’ it will be broken.

@pokoli

This will allow yo to add the constraint and also includes a separator (’-’) to be able to keep the original code if required.

Besides that this still breaks the original legitimate usage of the field. And doesn’t provide without further code changes a consistent creation of new codes.

@pokoli

This allows each company to fix the codes in a single maner depending on their business use. As we support all business we can not provide a single solution for all cases.

You didn’t answer my proposal (see above). I would be glad to hear if I missed something. An SKU for me in fact is an identifier. For me it turns out that adding this constraint was a wrong concept in the first place and should be fixed. And it is still easy to fix with the next bugfix release so that users hit by the incompatible change can upgrade to a next version without breakage.

Please read again the following citation that describes the situation very well:

@sergyo

IMHO it goes against to the argument I’ve always read in the Tryton community from my earliest days about giving a solution with minimal restrictions.
In fact unique keys have been removed from many models along versions.
Having an unique code is not a common requirement.

@pokoli

You have to look deper to see the light on the tunnel

Hmm.

[ced (Cédric Krier)]

There will be not turning back on this (and we will add more missing unique constraint on code field). This change is 4 months old. It is pointless to come after the battle (if you care, be involved in the development process). Also this is the basis for upcoming new functionalities and solve existing issue.
Tryton is evolving on each release and so each one will keep introducing non-backward compatible changes. We already provided many ways to bypass this constraint. But the most obvious and general one is that if you do not like the usage of a standard field, create a new one.

[risto3]

@ced

There will be not turning back on this (and we will add more missing unique constraint on code field ). This change is 4 months old . It is pointless to come after the battle (if you care, be involved in the development process). Also this is the basis for upcoming new functionalities and solve existing issue.
Tryton is evolving on each release and so each one will keep introducing non-backward compatible changes. We already provided many ways to bypass this constraint. But the most obvious and general one is that if you do not like the usage of a standard field, create a new one .

I find only two references of ‘SKU’ here prior to falling across it as ‘fait accompli’ in release notes.

Definition of FAIT ACCOMPLI

Couldn’t seem to find any references at all in years of mailing lists.

These two references were found in discussions of e-shop of which we have no business interest therefore never even took notice since we are not retailers… Weren’t solicited for comment either even though there is quite a history of product oriented activity…

Pity such a stance.

[pokoli (Sergi Almacellas Abellana)]

@risto3

Weren’t solicited for comment either even though there is quite a history of product oriented activity…

We can not request everyone to add comments in every new feature.

Having said that I think the current development process is quiet open:

• There is a lot of discussion that happens openly in this forum. You can receive a digest my mail if you do not want to be notified for each post.
• All the new features are linked to an issue on the tracker. You can subscribe to email to new issues to see all proposals and join on what you prefer.
• Anyone can post comments on the tracker or on the codereview tool.
• There is a list to get notified by each commit pushed. Normally this is to late to change things but at least you will now what it’s done
• The development sources are quite stable. You can try new features on a fresh database to try to fix things before there are relased.
• There is a feature freeze perios to fix bugs before the version is released.

But despite having such options there are always people complaining after the release

I can understand the frustration of having an unexpected change on a new relase, but please also understand that is quite frustrating to get comments trying to force others to change some part of a base module after ignoring all the possible solutions that can appplied to adapt the system for your needs.

Open source project work when everyone puts it’s efforts to work for a common goal and takes care of reviewing new features before they are released.

Honestly, I will love to have more eyes reviewing features before they are commited and I do a big effort to review as much as possible. But for sure we need more people to work on it.

[risto3]

I again invite then to fix rapidly this high impact regression:

1. change the name of code to sku (or inventory code) since it is no longer the product code
2. add mpn or manufacturers product number to allow previous usage of code to continue normally
3. add brand and possibly manufacturer, even model which are already missing
4. fix all the uses, in purchasing at least, to search these fields (in fact, sku is normally just an optional merchant specific identifier, at best it may be the suppliers code for the mpn, but not always, we have more and more suppliers using the mpn now)

[pokoli (Sergi Almacellas Abellana)]

@risto3

add brand and possibly manufacturer , even model which are already missing

This is a new feature that should be discussed on a separate thread. BTW the brand can be represented as a product category