Retrieve linked record without coding secondary table name?

I’m using the curl API to pull json data from a table linking to records in a secondary table.

I have a working function that pulls down and parses both tables. It then uses the record ID listed in the main table and plugs in the corresponding data in the secondary table. It works fine.

But it would be very helpful to perform this without coding the name of the secondary table. Is there any way to retrieve the name of the table source of the linked record without knowing it ahead of time? Or retrieve the record with just the ID and not the table name?

Hi Andrew, you could add a formula field in your primary table that just displays the secondary table’s name as text. The formula would just be: “SecondaryTableName” . Then that field would show up in every record and you can use in your code once you retrieve the primary table records.

Thanks openside. That could work. I was also just thinking about putting the name of the secondary table in the name of the linked record field.

I guess they’re both open to user error. But it’s better than nothing.

This is certainly an ugly issue because APIs should be naturally efficient about retrieving data given any single record ID. Lacking an API that supports helper methods to interrogate the schema and relationships, we’re basically on our own.

In a 25,000 record table, that’s 24,999 times the amount of data space actually required. :wink: Sure, it would work, but oh my - what a waste of resources.

Before doing that, consider using the table ID concatenated with the record ID (delimited with a dot or something). That would be at least a little more space-efficient.

Possible Better Hack?

What if you added a new field (such as “Linked Table”) and on one record – and one record only - you populate this field with the secondary table name?

  • As we know, the API never returns empty values, ergo - this Linked Table field will never be visible in the JSON results (except for one record).
  • We also know that a query to find the Linked Table requires only that we filter based on Linked Table != "" (i.e., not empty).
  • In a dynamic environment, a single query into the primary table returning a single result record would provide the secondary table name without forcing any bloat in the primary table, and without redundant values nor any redundant filters that need to process.

This proposed approach is simply a less pukey hack that requires an interrogation of the primary table. However, it would be relatively performant and would meet the need for a single API process to perform dynamically driven linked table identification.

I think that single record method is a good one. If my table were only ever referencing records from one other table at a time. But I want to build this system that might have one column referencing one table, and another referencing another. Your method could still work there, but gets a bit harder to keep track of.

And, my tables (at least now) are considerably shorter than the 100 record pull limit. So resource efficiency is a lower priority for me than simplicity of use.

Not true - simply create multiple Linked Table cell values that each map into their respective indexed fields. This would support (n…) linked fields for the table and discovery would be dynamically sound.

Ergo, if you query for a single record result where [‘Linked Field’] != blank and more than one exists, you can now enumerate the results and know that each such field is indeed a link field.

Why is the 100 record pull limit relevant to this conversation? I don’t follow.