# Update database after the last update on dev
**URL:** https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543
**Category:** Developer
**Created:** [April 6, 2020, 9:40am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543 "2020-04-06T09:40:41Z")
**Posts on this page:** 9
**Page:** 2
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [May 12, 2020, 9:57am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/21 "2020-05-12T09:57:49Z")
> [@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:
```sql
update product_product set code = CONCAT(code, CONCAT('-', CAST(id as varchar))) where COALESCE(code, '') != '';
```
This is the easiest solution to solve de problem.
---
### Author:  [@risto3](https://discuss.tryton.org/u/risto3)
#### Post date: [May 12, 2020, 10:30am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/22 "2020-05-12T10:30:54Z")
👎 don’t change the codes that have been created for a reason (read: business use)
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [May 12, 2020, 10:49am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/23 "2020-05-12T10:49:23Z")
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 😉
---
### Author:  [@yangoon](https://discuss.tryton.org/u/yangoon)
#### Post date: [May 12, 2020, 11:41am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/24 "2020-05-12T11:41:14Z")
> [@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.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [May 12, 2020, 12:06pm UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/25 "2020-05-12T12:06:47Z")
There will be not turning back on this (and we will [add more missing unique constraint on code field](https://bugs.tryton.org/issue9322)). This [change is 4 months old](https://bugs.tryton.org/issue9004). 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](https://bugs.tryton.org/issue9010) 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**.
---
### Author:  [@risto3](https://discuss.tryton.org/u/risto3)
#### Post date: [May 13, 2020, 6:23pm UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/26 "2020-05-13T18:23:16Z")
> [@ced](#):
>
> There will be not turning back on this (and we will [add more missing unique constraint on code field](https://bugs.tryton.org/issue9322)). This [change is 4 months old](https://bugs.tryton.org/issue9004). 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](https://bugs.tryton.org/issue9010) 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](https://www.merriam-webster.com/dictionary/fait%20accompli)**
>
> a thing accomplished and presumably irreversible… See the full definition
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.
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [May 13, 2020, 9:12pm UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/27 "2020-05-13T21:12:35Z")
> [@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.
---
### Author:  [@risto3](https://discuss.tryton.org/u/risto3)
#### Post date: [May 31, 2020, 9:47am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/28 "2020-05-31T09:47:47Z")
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)
---
### Author:  [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [May 31, 2020, 10:03am UTC](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543/29 "2020-05-31T10:03:57Z")
> [@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
[Previous page](https://discuss.tryton.org/t/update-database-after-the-last-update-on-dev/2543.md?page=1)