List joins or repeating groups ?

[Ecovoyageurs]

Hello,
In many cases, where we have to organize datas with parent > children approach, we can use both list joins or just repeating groups.
If I understand well, list joins creates a real different table whereas repeating groups creates a "kind of" children table (with ids linked to main table).
Please correct me if I'm wrong : list join seems more appropriate when we need to edit each child row independently whereas with simple repeating group we have only one form to edit at the same time parent and children datas.

Is there a difference for optimization and queries ?
Any other important difference I forgot ?

Thanks

 

[rob]

Since Fabrik 3.0, there's no real difference behind the scenes between creating list joins and creating repeat groups. Both will store the chid records in separate rows in the child table. The difference is that if you set a normal group to repeat, Fabrik will create the joined tables for you (saving you a bit of time) where as creating the lists/tables separately gives you more control over the naming of those db tables.
Of note, that prior to Fabrik 3.0 a repeat group would store the repeating data in a single table cell, which was a terrible design decision on my part

 

[Ecovoyageurs]

Yep, I've seen the differences between repeating datas : in a table cell for groups and below/above rows for lists.
OK I'll give it a go for different lists then.
Thanks for the explanation !

 

[teamwork]

I am using joined lists for repeating data, as opposed to repeatable groups, and am having an issue with the field that is joined not having the correct default value...
This is happening only on creation of new records... what is the proper way to have the relational column be set to the new record's id by default?

 

[cheesegrits]

That should just happen automatically, as long as your join is set up such that the FK (foreign key) on the "child table" points to the PK (primary key) on the parent table, and has no ACL's on the element that would prevent values being written to it (so don't set write access to "Special", for example). So for example, if your main table is "customers" and your child table is "invoices", you wuld need to join from customers.id to invoices.customer_id, and make sure the custoer_id element is writeable.

You'd need to post a screenshot of your list join settings, and the element settings for your FK element on the child table, for us to check to see if there's any obvious problems.

-- hugh

 

[teamwork]

Hugh, do you mean that the database itself must have the foreign key defined, or do we not have to have the foreign key also assigned in the database?