Update parameter case storage in data base

[stephprince]

In #150, parameters were updated to be tuples of dictionaries. In the results files these parameter cases are strings.

For querying data from the database and getting information about what data modality / object we are testing, it would be helpful if either we:

1. Converted the string type parameter_case column to a polars.Struct type to more easily query individual parameter values. Missing dictionary values could be normalized to be null if not present.
2. Added the parameter case dictionary values as separate columns in the results database ("name", "https_url", "object_name", and "slice_range")

@CodyCBakerPhD @rly any thoughts? I could handle this in the _app.py file and bump the database version so the current results file format would stay the same.

[CodyCBakerPhD]

For database querying, flattening into separate columns is typically more convenient than nesting values, but it's really whatever is most convenient for you

You can also generate these databases locally using the same functions the app calls and manually contribute them (the server does not automatically stay up to date with code changes, sorry). The server is just meant to be a quick/easy way to rerun stuff on a CROn basis once it is stable

and bump the database version so the current results file format would stay the same.

Hmm I believe the 'database' reference there is to the entire results (namely JSON structure) not per se the 'style' of the Parquet files. It's meant to be used by the 'to parquet' function to allow easier exclusion of ill-structured past versions

[stephprince]

For database querying, flattening into separate columns is typically more convenient than nesting values, but it's really whatever is most convenient for you

Great, yes I would prefer flattening.

You can also generate these databases locally using the same functions the app calls and manually contribute them (the server does not automatically stay up to date with code changes, sorry). The server is just meant to be a quick/easy way to rerun stuff on a CROn basis once it is stable

Sounds good. Yes I've been generating new databases locally just to test out some initially querying. I can manually contribute them once we're happy with any changes.

Hmm I believe the 'database' reference there is to the entire results (namely JSON structure) not per se the 'style' of the Parquet files. It's meant to be used by the 'to parquet' function to allow easier exclusion of ill-structured past versions

Ah ok, thanks for clarifying. So when concatenating the results, I could start excluding files <v3.0.0 if we want to only include results with the newer parameter case format. Do we want to be including all versions for now?

[CodyCBakerPhD]

Do we want to be including all versions for now?

For that I defer to @rly who knows more about the underlying benchmark structures relative to what we currently want to test

[rly]

For results, I would use only ones that use the newer parameter case format. I might even say that we should limit to certain runs, since some of the earlier runs were on my laptop while I was in zoom meetings and doing other things.