BDMS 22: Implement the sample model in SQLAlchemy POC so that a set of staging data can be displayed in data manager

[jacob-a-brown]

Why

This PR addresses the following problem / context:

• A new sample model was implemented, and then updated after the initial implementation.

How

Implementation summary - the following was changed / added / removed:

• Updates to the sample model, mostly for non-nullable fields
• Updates to schemas to include the new fields, restrictions, and validations
• Updates to the sample fixture and tests for the new model and schemas

Notes

Any special considerations, workarounds, or follow-up work to note?

• Since PATCH and POST endpoints require the same field validators, a base validator pydantic class is created from which CreateSample and UpdateSample inherit.
• There are many shared fields throughout, but some of them are required for CreateSample and are optional for UpdateSample. Should we try and find some clever to inherit and set fields to optional or not?
• There are some development notes in here for future selves
• There are some questions that have yet to be answered and decided upon. These are noted in REFACTOR TODO notes throughout the code base
• per PR fix: added optional thing_id to the BaseAsset schema. fixed sample tests to use singleton asserts instead of asserting equal dictionaries #61 changed sample tests to use singleton asserts

[chasetmartin]

Instead of using field validators for sample top / sample bottom, could you use a @model_validator that runs once on multiple fields after pydantic does its other validations, like:

class CreateSample():
    ...
    
    @model_validator(mode='after')
    def validate_sample_topbottom(self) -> 'CreateSample':
        """
        validate sample_top and sample_bottom are provided together
        """
        if (self.sample_top is not None and self.sample_bottom is None) or \
           (self.sample_bottom is not None and self.sample_top is None):
            raise ValueError("Both sample_top and sample_bottom must be defined together")
        
        return self

Would this help with logic duplication between top and bottom field validators?

[jacob-a-brown]

@model_validator is probably the way to go. One of the things that I like about @field_validator is that it indicates in the response which fields were invalid and why, so if you want to display the error message beneath (or near) the invalid field it's easy for you.

In the response from @field_validator, for example, the invalid field is pointed to by "loc": ["body", "sample_bottom"]

Nevertheless, from reading forums and chatting with CoPilot @model_validator seems to be the best way to perform cross-field validations. And, if you want to proceed with error messages next to/near invalid fields, we can figure out how to do that efficiently/correctly with @model_validator

[jirhiker]

looking good. a few minor change requests