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.
4 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.
2 Likes
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.
When I first installed Frappe 10 days ago and followed the tutorial to create my first Doctype, I was shocked to find that the primary key wasn’t the commonly accepted “ID” but rather “name”—and it was even editable! That was truly surprising.
I know you are an experienced expert in databases and related fields. If there is one thing that would help me the most, it would be resolving this doubt in my mind: Can Frappe be reliably used for developing enterprise software?
The moment I saw pk = name, this question arose. However, ERPNext seems to prove Frappe’s reliability. So, as a beginner, I would really appreciate your advice—Is Frappe a reliable framework for enterprise software development?
The term “enterprise software” is just so subjective. And ERP is such a gigantic, complicated thing.
My general opinion is that Frappe Framework/ERPNext is quite reliable for small to midsize businesses. I’ve been using it successfully for many years. So have many people here on the forums.
I wish I could tell you there’s a firm boundary, that once you cross it, the product changes from suitable to not-suitable. A specific number of concurrent Users, or “transactions per period”, revenue, number of employees, or size of database. But I cannot: that’s not how it works. The real world situation is far more complicated than that.
I’ve been living ERP for about 20 years. Here’s how I feel it should work: when it’s time to choose you perform what’s called a “Fit-Gap Analysis”.
-
What are the Requirements for my business?
- Budget
- ERP Modules / Verticals (accounting, retail, supply chain, manufacturing, payroll, etc.)
- Special features specific to my company’s needs (e.g. perhaps my company does a lot of equipment Rentals; in that case I want an ERP really strong in that area)
- Integrations you require to 3rd party services and software.
- Reporting and Analysis requirements.
- Performance (how much activity must the ERP smoothly handle?)
- Security, Hosting.
- Language Support, and Locations of Employees (single office, same city, same country, or worldwide?)
- Current Tech Stack (e.g. if my company already uses tons of Oracle-based software, I may not want a Microsoft-based ERP.)
- Flexibility/customization (do I have my own software programmers, contractors, or not at all.)
- What kind of Support do you require from an ERP Vendor/Partner?
- Dozens more questions. You want to build a very detailed Requirements Document.
-
Does the ERP software Fit my requirements?
-
Hire consultant(s) who are already an expert in the ERPs you are considering. Have them perform the Fit Gap analysis for you.
-
Try to determine suitability yourself through demos, customer testimonials, chat with people already using it, personal experimentation, etc.
-
-
For all the Gaps you identify, can you …
- Live with the gap?
- Find a workaround? (e.g. change a business processes to use what the new ERP has)
- Modify the ERP to make it work?
Depending on who you are, and what you need, this process could take days, weeks, months, or longer. It’s a big decision. Switching ERP software is very costly (time, money, effort). So you want to gather as many facts as you can, and make an informed, wise decision.
You make your choice and begin to implement. If you work hard, and get a little lucky, then everything turns out okay at the end.
There are many things I -really- enjoy about Frappe Framework and ERPNext.
There are likewise many things I really -do not- like. The whole 'name' thing is certainly one of those. That being said, while annoying, it hasn’t prevented me from accomplishing my goals. It’s just something I live with and work around.
If you have some specific questions or requirements, definitely share and ask those before moving further: choosing an ERP is one of the most important decisions a company will ever make.
4 Likes
I agree with everything @brian_pond is saying here. Just to add a bit about how primary keys work in Frappe:
Preferences for the primary column are subjective. Personally, I like id, hate pk, and think name is fine enough. It’s more a question of aesthetics than functionality.
The more important question is how primary keys are structured. Frappe gives you a lot of flexibility in this regard. If you want to use an editable semantic name, you can. If you want to use an uneditable increment or hash/uuid, you also can. In principle, I think that flexibility is good.
That said, there are definitely some doctypes in ERPNext that I think made the wrong call, using semantic/editable keys that should have been arbitrary and fixed. What you do in any application you’re developing is up to you. You could, if you wanted, just use an auto incrementing value for everything.
2 Likes
@brian_pond @peterg
Thank you both for your support. I truly appreciate your sincerity, professionalism, and attention to detail. My doubts have been resolved.
ERP selection and implementation are incredibly important and serious. I will take my time to think it through carefully, and if I encounter any issues, I will come back to seek your advice—even if they are unrelated to Frappe. Your help has given me great reassurance.
2 Likes