Hello everyone,
Why default primary key for doctype name is “name”? not pk or id?
Because its weird if i fetch api for Product Doctype like
product.name (for id)
product.product_name?
Can i change it to pk or id?
Thank you
1 Like
Probably for historical reasons:
A software first built by a small team and then successively extended to fit their evolving business, then further extended to fit the use cases of friends and friends’ friend’s other business use cases.
In other words, it started small and simple, and then became a bigger and more structured network of interrelated business objects modeled in the system. Since more and more people used and use it, it tried to evolve smoothly and gently without breaking too much stuff going forward.
How would you build and market and continue to build and market such a thing, otherwise?
As far as I’m concerned, it makes sense. We’re all humans, aren’t we?
And it’s still free as in FLOSS!
1 Like
Wha’s in a name really 
Solving “why” questions on these forums is very difficult.
The answer to your question is "because some person(s) decided this back in 2010, for their own reasons."
If you are extremely lucky, this person:
- Is still alive today.
- Is still using these forums.
- Sees your question above.
- Decides to reply with the answer.
Otherwise, we’ll never truly know.
Practically…no.
You would have to fork both Frappe and ERPNext, and make a substantial number of code modifications.
3 Likes
Or you find answers in git’s history preservation. This you can simply download with the archives.
And as long as Microsoft keeps the github history available (ideally freely – but no guarantees I’d suppose), you can also learn and understand more from that, although all these discussions of issues, PRs etc. on github are another lot of material. It may be more to the point of the actual code evolution than many forum discussions, though, although these latter could be correlated with the changes occurring.
So, you don’t just need to hope somebody competent sees a quest for your knowledge of this kind, but you can actually dig yourself into the traces of the human evolution of this domain specific knowledge.
So, you don’t just need to hope somebody competent sees a quest for your knowledge of this kind, but you can actually dig yourself into the traces of the human evolution of this domain specific knowledge.
Your optimism is admirable, but unrealistic. You may find some well-documented explanations of bug fixes or small enhancements. But in most cases, developers are not uploading their inner thoughts into GitHub when they design something new. For example, 15 years ago when Rushabh decided to use the letters 'name' instead of 'id' as a primary key? I’m quite confident he didn’t sit down and write a dissertation about his reasoning in a GitHub commit, pull request, or issue.
Some developers may choose to blog about these things. Or publish a technical paper. Or include answers to “why” questions in the project’s documentation. I’ve done this myself on occasion. But even then, I didn’t explain every table, column, and function. Why I chose the names I did. And why I wrote the code lines I did. Nor have I ever seen another developer do this.
But you’re correct, it’s technically possible. So for the sake of completeness, I will revise my prior point:
If you are extremely lucky, this person:
- Is still alive today.
- Is still using these forums.
- Sees your question above.
- Decides to reply with the answer
or
- Took the time to write a detailed explanation of their motivations, decisions, and reasoning, and uploaded that text to GitHub, along with their code.
Either way, keep on hoping.
Also, I have no idea what you mean by human evolution, or domain-specific knowledge. We’re talking about the name of a column in a SQL table.
Yes, but the different traces and this forum provide some context to where the devs (and other personnel) and the project stood at this or that time (of where the traces come from).
In a way, and I just thought about it this morning, the whole thing reminds me of embryology, because embryos kind of fast-evolve through a repeating of recognizable states of the whole of evolution up to where they are. Much of it is very rough of course, there are short-cuts and other non-mappabilities of “then” to the “now” of how it evolves in the individual, but you get an idea, albeit incomplete and approximative, of how many aspects of the species and their ancestors evolved. There is a lot of chemistry and genetics etc. going on while this happens.
And the framework+ERPNext reminds me of that in the sense that if I put myself in the shoes of the devs in their evolution of working on the software over time, many of the quirks and strangeties suddenly make sense to me, because I need to learn stuff that they also needed to learn and find out in order to advance with the project. Starting small, and growing from there. Who doesn’t start small with this project and grows with it over time? So I guess part of the learning is understanding from where they came and the path they took to build it. Even without guaranties that theses guesses are correct. Still it helps, as far as I am concerned.
The “hope” came from your post, because I consider this:
as an expression of hope, but of course you don’t recommend it, while I say you don’t need it because you can advance on your own instead of “just hoping” (passively – implied --, as you seem to consider “hoping” as such; as seen in other posts from you).
With “domain-specific knowledge” I meant what you learn when working on implementing this software somehow. The specific stuff you need to know to do it. From the field you’re working for, but also from what you need to know about the software. Two fields to connect, which one could even consider a third domain in itself.
But you can do without all this, everybody advances in their own way, and hopefully happily so. That’s at least my wish for all of us.
You have a part in this because your posts are very often useful and interesting.
A name should ideally be something that can be changed without causing a ripple effect across every linked document.
Initially, I found the idea appealing due to its readability and simplicity. However, I soon realized that handling renames becomes quite complex. ERPNext even restricts renaming for key documents like Warehouse and Batch, which feels like a significant limitation and, in my opinion, poor design.