test(robot-server): Test for SQL parity between metadata.create_all() and the migration path

[SyntaxColoring]

Overview

This covers EXEC-827 with a test. The test is currently marked as expected-to-fail. See EXEC-827 for background.

Test Plan and Hands on Testing

None needed.

Review requests

Are the names and docstrings clear?

Risk assessment

No risk.

[sfoster1]

Seems like the right direction to go. I'm a little confused about the intent behind all of this, though. Like, if we're going to be writing out the sql command strings anyway, why not just... write them out? It feels like we're tying ourselves in knots for the sake of a kind of mediocre statement mapper.

[TamarZanzouri]

looks good! thank you for fixing this!

[SyntaxColoring]

I'm a little confused about the intent behind all of this, though. Like, if we're going to be writing out the sql command strings anyway, why not just... write them out? It feels like we're tying ourselves in knots for the sake of a kind of mediocre statement mapper.

@sfoster1 Are you asking why use SQLAlchemy at all? Or just, why use SQLAlchemy for declaring the tables?

If the former, I think SQLAlchemy is a net positive despite its complexity. That's a bigger discussion and I'm happy to expand on it outside of this PR.

If the latter:

• Some of our columns are more than just straight passthroughs. e.g. we have datetime and enum validation. So the Python-side table declarations do add some meaning beyond what you can express in a raw SQL string.
• Even putting those columns aside, I'm not sure it would be possible to just write the raw SQL strings here without giving up on the rest of SQLAlchemy, just because of the way SQLAlchemy works syntactically.