New Script: Same Table Linked Records Backlinks

Could you please point out where the recursion and inheritance occur?
I’m not seeing either.

I also find a few things in the script to be rather curious, such as line 67:

if(!currentAddedKidParents.includes( { id: modifiedRecord.id, name: modifiedRecord.name })) {

I bet this line does not do what the author intended. This condition will always evaluate as true. When using .includes() with an array of objects, JavaScript checks if the objects themselves are included, not the contents of the object. As written, the newly created object will never be included in the array, even if the array has an object with the same property values. Thus the includes() will always be false, and the ! negates that , making the condition always true.

There are a few other things in the script that imply that the author had limited experience with Airtable scripting when he wrote the script. For example, every pair of updateRecordAsync calls could be condensed into a single call, which would cut the run time almost in half. (And there are several other changes that could speed up the script, such as not having updateRecordAsync inside a loop.)

Could you please point out where the recursion and inheritance occur?
I’m not seeing either.

Sure, I haven’t been wrong all day, got to start somewhere :grinning_face_with_sweat: : is the findChildren function not both recursive and prototypal in places? The latter because it implicitly inherits the getRecord method and just rolls with it?

The former because of the way it creates its tree object, for example? Its async sync queue trigger is kind of recursive as well, it has a single stop/start condition and the interpreter is left to figure out the best ratios. This all comes together to form a solution that should work in any base, regardless of size, as syncing part keeps it keeps reusing its few functions for roughly (records.length/50)+1 cycles. or other properties - assuming the initial setup was correct.

Basically, it should work in any base, regardless of size and other properties, because it keeps switching between filling the queue and clearing it, for as long as needed.

Why do I have a feeling I’m flunking math and just how many scripts have been posted so far, I can’t even find that line 67. The thing I’m looking at and was looking at originally is a gist, I’m leaving just the canonical url here because some filter keeps complaining about repost attempts:

/on2air/b68450a877ab99fe4a93ef7f9c387568

And my original point was that this was good, not that the other thing was bad.

Scripting has undergone a lot of changes since this thread was started.

I decided to write a new version of the script to take advantage of some new features, such as script settings, that lets the script remember the table and fields without having to touch the code.

This version has a few differences from the original and is entirely my own code, although aspects of the algorithm are similar.

• uses script settings for setting table & fields (which did not exist before)
• works on only one table, not multiple tables
• does not allow limiting records to a view
• various speed improvements and error checking

This script is best used as a batch update when first setting up back links. I also have a matching automation script for when either the link or the backlink is updated, without needing to store previous versions of links. If you are interested in the automation script, please book an appointment with me.

Scripting has undergone a lot of changes since this thread was started.

I decided to write a new version of the script to take advantage of some new features, such as script settings, that lets the script remember the table and fields without having to touch the code.

This version has a few differences from the original and is entirely my own code, although aspects of the algorithm are similar.

• uses script settings for setting table & fields (which did not exist before)
• works on only one table, not multiple tables
• does not allow limiting records to a view
• various speed improvements and error checking

This script is best used as a batch update when first setting up back links. I also have a matching automation script for when either the link or the backlink is updated, without needing to store previous versions of links. If you are interested in the automation script, please book an appointment with me.

This is great @kuovonne, we need this (for parent / child relationships) but we also need one for sibling relationships… i.e. only one linked field with multiple entries.

E.g.

Running the script on:
Name Siblings
1 2,3
2
3

Should lead to:

Name Siblings
1 2,3
2 1,3
3 1,2

Is this possible? Or is there a workaround?

I’ve tried achieving this with automations, breaking out sibling IDs as separate formula fields and using lookups to create the updates… however this creates a recursive loop which I can’t seem to stop.

Help would be greatly appreciated!

It is possible to have a script to update sibling relationships. There are two potential scripts: a button script for establishing siblings relationships for existing records, and an automation script for maintaining sibling relationships on an ongoing basis. An automation script can include logic to avoid the recursive loop of unending automation runs. Please let me know if you are interested in hiring me to write these scripts.

However, usually sibling relationships are managed through a parent record. All of the siblings are linked to the same parent. The parent rolls up information about all the children/siblings, and then another rollup field passes the necessary information back down to all the children/siblings.

Hi @kuovonne thanks for offering your help. Yes, I’d appreciate your help with this. I’ve explored a parent record approach, but this seems more clunky. Since our focus is on each individual client, it’s best to know specifically who their family members / relationships are (spouse, children, parents, siblings, in-laws, extended family).

I’ve already used your script for spouse / children. Thanks for posting that.

How can we liaise with you to get you to write an automation(s) for siblings, in-laws and extended family in our contacts table?

Scripting has undergone a lot of changes since this thread was started.

I decided to write a new version of the script to take advantage of some new features, such as script settings, that lets the script remember the table and fields without having to touch the code.

This version has a few differences from the original and is entirely my own code, although aspects of the algorithm are similar.

• uses script settings for setting table & fields (which did not exist before)
• works on only one table, not multiple tables
• does not allow limiting records to a view
• various speed improvements and error checking

This script is best used as a batch update when first setting up back links. I also have a matching automation script for when either the link or the backlink is updated, without needing to store previous versions of links. If you are interested in the automation script, please book an appointment with me.

Scripting has undergone a lot of changes since this thread was started.

I decided to write a new version of the script to take advantage of some new features, such as script settings, that lets the script remember the table and fields without having to touch the code.

This version has a few differences from the original and is entirely my own code, although aspects of the algorithm are similar.

• uses script settings for setting table & fields (which did not exist before)
• works on only one table, not multiple tables
• does not allow limiting records to a view
• various speed improvements and error checking

This script is best used as a batch update when first setting up back links. I also have a matching automation script for when either the link or the backlink is updated, without needing to store previous versions of links. If you are interested in the automation script, please book an appointment with me.

Maybe one suggestion:

Suppose you have 3 columns: organizations, is_funding, is_funded_by

They are populated like in picture 1.

Then you make some manual changes, resulting in picture 2.

Then you run the script with is_funded_by as Original Link and is_funding as Back Linked Field, expecting the dependent field of both of your changes to be populated automatically.

But the result is picture 4

And if instead you had done 'is_funding as the Original Link and is_funded_by as the Back Linked Field, the result would have been

But the result you’d want is:

With either solution you lose data. It is possible to avoid this problem by running the script every time before you make a change in a field that is dependent on a field that you just made a change in, but this is inconvenient, especially when lots of changes are made in short periods of time.

Maybe the script could give a warning if it detects that you are about to make changes that would overwrite unsaved changes in dependent fields. But this could get annoying fast. So maybe at the start the script could temporarily create an extra column in which it pastes the unsaved changes from one side of the mutually dependent columns, and then once the script has done its thing it adds the unsaved elements that got overwritten but a copy of which was saved in the temporary column, and then it automatically deletes that temporary column before finishing.

(it’s also possible that the script already solves this problem but that I am just not using it properly)