[uuid] Why core Doctypes lack of protected unique identifiers?

[AlvaroMolano]

Hello all, I know there are some old posts about the subject, but did not found the answer I am looking for. It seems to me there is not much importance given to unique identifiers in core doctypes. I noticed the user model has an idx. but generally, queries are based on .name field which can change on time.

So, 1 . how do you manage to make sure your site will not break when the user has ie: changed his name, or when an article is renamed.
2 Why the core team does not give more relevance to safe queries against fields that will not change on time?

I am working on version-12, I would add in frappe or erpnext to some core doctypes the field uid and set the naming series. But, I am afraid after an update or a migration this gets broken. 3. What does the community suggest?
4 What would be the process to persist those changes in a safe way?

Thanks

[neerajvkn]

wondered the same especially for customer doctype, would make fetching docs related to those customer a lot easy since we will not have to worry about 2 customers with same name,

1 - core docs can have custom naming series defined, 4 - create a custom app and set a naming series for that core doc.

[max_morais_dmm]

There’s no real needance for UUID, except in cases where you are handling with partitionated databases.

In case of ERPNext, the hability to rename and merge, is the way to go, to solve minor issues like when it happens, and frappe framework provide events to manage renaming and merging documents, and what should be the behavior.

Also you are right that erpnext dont comply when you change the email of the user, when it’s supposed to be renamed, it’s not. I think it’s a bit ugly, but keep things a bit consistent.

Also idx doesn’t serve as the purpose you are thinking about.
Idx is an ordering integer field, that is used, when the User doctype get embbeded in a child table, so the idx field will be filled, to preserve the order of the rows, on the UI.

You can use the doc_event, before_naming, to implement your own policy, to move all doctypes you want to make use UUID, but you will see that Link fields, have an lack of title handling, when it happens and you will end-up with screens like that one

[felix]

You can disable the ability to rename by unchecking “Allow Rename” in doctype settings. This has to be done per doctype.

[AlvaroMolano]

Thanks for your comments

[AlvaroMolano]

@max_morais_dmm, It is taking me some time to get to understand the mind behind this framework, it is nothing like I am used too, it is very opinionated besides all that flexibility. My experience is from Java + Javascript mostly, so for someone like me coming from Spring Boot or Android or iOS or Angular or React is a huge change when trying to get into the core of Frappe.
Thak you!

[AlvaroMolano]

When UUID is needed

There are many reasons to add an id field to a document and make it a trust uuid that never changes. A .name identifier might still be useful when renaming documents.

UUID

1. Doctype needs to be customised by adding an (‘id’) field of type(‘data’) it can be hidden and obligatory.
2. Create a Custom Script for the Doctype and add a JS function to assign a UUID on save. This one is based on the creation timestamp.
   ´´´
   frappe.ui.form.on(‘’, {
   validate(frm) {
   function create_UUID(){
   var dt = new Date().getTime();
   var uuid = ‘xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx’.replace(/[xy]/g, function(c) {
   var r = (dt + Math.random()*16)%16 | 0;
   dt = Math.floor(dt/16);
   return (c==‘x’ ? r :(r&0x3|0x8)).toString(16);
   });
   return uuid;
   }
   console.log(frm.doc.id)
   // your code here
   if(!frm.doc.id | frm.doc.id === ‘’ | frm.doc.id === ‘None’){
   frm.doc.id = create_UUID();
   }
   }
   })
   ´´´

I should try to make it in python for performance reasons but.
Adding changes to Core is long process and something like this will probably be rejected. Maintaining code out of the official repository is not worth the effort.
The other option is to implement it trough a custom app, but in frappe_docker you can not yet install apps on existing sites.

[tionebrr]

I’m starting to use ERPNext and I was thinking exactly the same thing. I’m surprised that not all the database entries have a unique IDs.

Some have a kind of ID, like the Item Alternatives.

Also, isn’t parsing the fields and changing them in the database kind of frail? What happens if you change an item name and the server crashes during the parsing/change phase? Do you end up with unlinked entries and inconsistencies?

Because in this case an unmodifiable UUID for each entry would at least allow to detect and correct database inconsistencies.

What are your thought about all of this finally? Did you continued using ERPNext as is?