Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add custom field to test_results table #1116

Open
matsduf opened this issue Jul 6, 2023 · 1 comment
Open

Add custom field to test_results table #1116

matsduf opened this issue Jul 6, 2023 · 1 comment
Labels
T-Feature Type: New feature in software or test case description
Milestone

Comments

@matsduf
Copy link
Contributor

matsduf commented Jul 6, 2023

When we run a batch test on the entire .se zone (or a random selection of that) we need to add registrar information for the interpretation of the result. For best performance we need that in the test_results table, but there is currently not place for that. We would like to have an extra field, preferably in JSON format to be able to add whatever subfields that we might need.

  • Create new field
  • Make it possible to add custom data per domain when creating a batch through the API

No other API calls need to support the custom data. For the use case, direct database queries are used to access the test results.

@matsduf matsduf added the T-Feature Type: New feature in software or test case description label Jul 6, 2023
@matsduf matsduf added this to the v2023.2 milestone Jul 6, 2023
@mattias-p
Copy link
Member

mattias-p commented Feb 12, 2024

The biggest complaint I have about this is that it makes Backend into a datastore for business data of other applications. IMHO that's just not sound architecture.

Should we, however, decide that we do want other applications to store their stuff inside Backend I have three other complaints, but those are technical in nature and I'm providing an alternative design proposal that remedies them.

Technical complaints:

  1. In effect this would make the database schema into a public API. I don't think that's acceptable. This really needs to be accompanied with an extraction API.
  2. When this proposal was created the batch feature was intended for internal only use, but since the F2F in January 2024 we're adapting the batch API for public use. I believe we don't want to expose this feature to public users.
  3. This feature is about attaching a piece of client data to each job, but only when creating jobs as part of batches. If jobs have client data in our data model, we should really allow attaching client data when creating singular jobs too.

Design proposal:

  • Add a RPCAPI.enable_client_data configuration property that accepts a boolean and defaults to false.
  • Add an optional client_data parameter to job_create that accepts an arbitrary JSON value and defaults to null. If RPCAPI.enable_client_data is false, the arbitrary JSON values must be null.
  • Make the domains parameter of batch_create accept an object that maps domain names to arbitrary JSON values. If RPCAPI.enable_client_data is false, all the arbitrary JSON values must be null.
  • Make the result object of the job_results response include a client_data property if and only if RPCAPI.enable_client_data is true.

@matsduf matsduf modified the milestones: v2023.2, v2024.1 Mar 19, 2024
@matsduf matsduf modified the milestones: v2024.1, v2024.2 Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-Feature Type: New feature in software or test case description
Projects
None yet
Development

No branches or pull requests

2 participants