PSM CLI, table persistence

[dogversioning]

This PR makes the following changes:

• Two types of tables are available, persisted outside of study lifecycle - a basic transactions log, and a list of all stats objects in a given study
• Stats specific:
  • stats tables have a timestamp of creation
  • a view will be created that points to the latest table
  • cli flags added for force recreate/removal
  • Cleaned up PSM flags allowing for access to small data sets
• Test data generator added for stats table sampling
• Added data_path as a class var to StudyBuilder/StudyParser to get a write dir to PSM
• StudyParser tests cut over to DuckDB for unit testing

Checklist

• Consider if documentation (like in docs/) needs to be updated
• Consider if tests should be added
• Run pylint if you're making changes beyond adding studies
• Update template repo if there are changes to study configuration <- will do this after review in case of any comments

[dogversioning]

I think I mentioned this in passing, but I wanted to call attention to 'you can now include arbitrary args when extending a tablebuilder' as maybe relevant for metrics work.

[dogversioning]

I made this change for my convenience, since I'm toggling between athena/duckdb fairly frequently. I can be talked out of it.

[mikix]

I personally liked how it worked before (big surprise) but I'm not passionate about it.

My reasoning stemmed from the fact that athena is the default. So a lazy user might accidentally be in athena mode (forgetting to pass --db-type) and if we don't stop and let them know (and how to correct their mistake -- hence my (try duckdb), because maybe they've never used that flag before), their clear user intent will be just dropped on the floor and they might think things are working when they are really not. A warning helps, but a straight error ensures they will notice that we didn't do what they asked.

But 🤷 maybe that user flow is not so important.

[dogversioning]

I'm changing this back for now for this PR, but i reserve the right to add a workaround of some kind in the future if it becomes a pain, perhaps some kind of dev only flag or something like that.

[dogversioning]

@mikix Known issues I will address that are not blocking review:

• I need to update unit tests to inspect records of the transaction logs/stats tables
• I have several inline SQL queries I should cut over to templates
• I'll deal with regression at the end

[dogversioning]

@comorbidity If you could - can you look at this file, and the linked PSM markdown file, on the branch just to check how parsable the overall documentation of this would be for a user?

[mikix]

I am going to mostly ignore the test file changes - my brain can't take it right now, and I trust they are good duckdb nonsense.

Approving - this is good! Feel free to land while I'm away

[mikix]

nit: this is an odd method construction. I understand why you might end up here reasonably, I'm just going to prod you to see if there's a better way to get at the flow you want. If not, this is fine.

It especially triggered me because stats_build=False is the default.

[dogversioning]

Here's what i believe stats generation lifecycle to look like:

• stats, if they exist in a study, are always run if they haven't been run before
• after this, stats should :not: be run
• a researcher may say 'ok, i've changed [x,y,z] and now i'd like to run a new sampling experiment, let me explicitly invoke it'
  So some sort of 'usually false' workflow belong someplace. It might be worth nattering a bit about the the right layer of seperation between the Builder and the Parser (and should the Builder be named something different)? but it could move to the builder.