I am resolving a static analysis scan result as a custom source plugin, and am breaking out the different sections of the scan into their own tables. Am I meant to use the relations field of the table schema to connect the tables (I’m using Go), or should I use a column resolver to add a custom identifier so I know which scans different results are derived from?
I couldn’t find an obvious example of using relations or parent tables, and it looked like in the k8s source it opts to add a UID via a column resolver.
Usually, you would use relations when resolving some data that depends on other data. For example, let’s say you have an API that returns a list of users and another API that returns phone numbers for each user when provided with a user ID.
You’d define an api_users table that lists the users, then a relation for that table named api_user_phone_numbers. Relations receive the parent item via the table resolver, so api_user_phone_numbers will use that to list a specific user’s phone numbers.
Based on the information you shared, a column resolver might work better. Maybe add a scan_id column. I’m not sure how you’re loading the static analysis scan, but you could initialize the scan ID on plugin init and then add that information to the client meta, which can later be used by a column resolver.
Makes sense! I originally asked because when populating relations I got a duplicate error, but I realized it’s because I forgot to remove the child tables from my client’s getTables implementation.
Another way would be to get the whole data in your struct, but don’t define some of the columns you’d like to move to other tables. If you’re using transformers to build your definitions, you can use transformers.WithSkipFields.
You can then define the child tables to refer to some fields from the parent. Here’s an example from an outdated version of a plugin (the newer version uses GraphQL):
Main definition where “Product” is defined but “Variants” and “Images” are skipped: Product Definition