Is there any way I can add child table inside a child table?

Frappe Framework
1

Is there anyway I can add child table inside a child table?

2

Hi @Abhiraj_Tulsyan:

See this:

And this:

Hope this helps.

3

@avc
I don’t just need for data output so I can’t use the second solution.

The first solution was never merged so how can I use that in my custom app?

4

Yes, child within a child would be very helpful & has been discussed a few times, but I don’t think it is on the current roadmap.

The only 2 workarounds I’m familiar with are:

  1. On the first child doctype, instead of storing all the data in the child table, make a field in the child doctype be a linked field to another (standard) doctype, and then you can put the 2nd child doctype on that standard doctype form that the first child doctype field links to.

Or,

  1. On the first child doctype form, in an HTML field create a custom HTML table that shows data for the 2nd child doctype. This second option obviously requires more custom development, especially if you want in-grid editing etc.

Neither solution is very elegant. It would be great if Frappe eventually supported nested child doctypes.

1 Like
5

Hmm :thinking:,

@Abhiraj_Tulsyan and @DCRob,

Child tables are used to represent one-to-many relationships between two DocTypes. Child tables allow you to store multiple records related to a parent document in a structured way. Each row in a child table represents a record related to the parent document.

The reason why nesting child tables (child tables within a child table) is not supported is related to the underlying database structure and the way relationships are defined. The current design of the data model doesn’t allow for direct nesting of child tables.

Here are some reasons why nesting child tables might not be supported:

  1. Database Structure: The database schema used may not be designed to handle nested child tables efficiently. Implementing nested child tables could complicate the database structure and may lead to performance issues.

  2. Data Integrity: Nesting child tables could potentially introduce complexities in maintaining data integrity and consistency. It might make it more challenging to manage and update nested data relationships.

  3. User Interface: The user interface is designed around the concept of child tables, and introducing nested child tables could complicate the user experience and UI design.

  4. Development and Maintenance: Supporting nested child tables would require significant changes to the ERPNext codebase. It might also introduce challenges in terms of maintaining and upgrading the system.

While nested child tables might provide a more flexible data structure in some cases, the current design choices prioritize simplicity, performance, and ease of use. The workarounds you mentioned, such as using linked fields or custom HTML tables, are ways users can achieve a similar outcome within the existing framework, although they may not be as elegant as having native support for nested child tables.

I hope this helps.

Thank You!

6

Hi DCRob, i am looking for solution for same problem.
I am new in this Frappe Framework, option one looking good solution for me.
Further question, after make a linked field in the child doctype, can we take data (one value of one field in this child doctype) and store automaticaly to one field of another (standard) doctype which is opened from that linked field?

7

Yes, I think you could do that. I’m not a programmer, but using a script you should be able to, if the standard ‘fetch’ feature of the Frappe framework isn’t sufficient.

9

There are at least two ways I know of for “doing” this, realistically, both using the built-in availability of frappe.DataTable, which provides a drop-in table element and data manager wherever you want one, including in child table forms.

The first “way” circumvents the need for an additional nested child doctype, by simply loading and saving structured data to a dedicated JSON field on your existing child doctype. This can be done elegantly and with little code, but presents some challenges to querying the data. The more recent addition of native JSON functions to MariaDB and PostgresSQL do help to close the gap here significantly. You can, for example, load, query, and join JSON data as native SQL data using JSON_TABLE. The advantage of this method is its elegance: it can be implemented entirely as a fairly minimal frontend script, and augmented with backend scripts, as necessary.

The second way is similar, but allows “true” nested doctypes by querying and saving data to/from an external child doctype/table into a frappe.DataTable. This preserves all the conventional doc and database API functionality for your nested doctype, but requires implementing backend methods to handle the data transfers on load and save… so a bit more scripting.

I’ve implemented both of these, and I hope to extrapolate and demonstrate a more general-purpose implementation of both approaches in the future. I personally feel that the strict child/parent designation for Doctypes is a weakness of the Framework, and deserves to be re-engineered, but that’s another topic for another time. For now, hopefully that spurs some thinking about what’s possible and can garner some scripting ideas.

2 Likes