Atlas for migrations?

[aehlke]

This could be a useful tool for generating migrations: https://atlasgo.io/

Static typing is undesirable for migrations due to keeping them in your codebase over time, but some kind of programmatic verification is helpful when using LLMs - so that they can evolve schema and have something like Atlas generate the migration from the schema changes, rather than handing migration SQL to the LLM directly which can risk more catastrophic results without close review.

[mbrandonw]

Hi @aehlke, Atlas is definitely interesting, but this seems like a fundamental rethinking of how migrations work in an iOS app. I think we should absolutely do that sometime soon, but for right now people can use the GRDB migration tools.

Having never used Atlas myself, I have some questions if you have experience with it:

• I imagine the "versioned" workflow is more appropriate for iOS apps than "declarative"? The declarative style applies migrations directly, but we can't do that at runtime in iOS. The versioned style generates migration files that we can load and apply at runtime. Is that your impression too?
• Does Atlas handle migrations that not only alter the schema but also need to migrate data? Like if you wanted to seed some data or backfill some data? It seems like it would be supported for the versioned workflow but not sure how it would for the declarative one.
• Can you explain a bit more concretely how this tool helps with LLMs? I couldn't find any info about that on the Atlas website.

[aehlke]

Sorry to share something without experience with it - I actually haven't used it yet myself but was reading https://x.com/steipete analysis of it

Re: LLMs, they have a tendency to do things like write and run a migration for dropping tables in order to make it easier to solve a bug (without any need to drop data). This is not as risky with client-local DBs and mutli-step app review processes unlike devs working with machine access to production services (though I've also made the case for sharing-grdb on more platforms including backend), but could still result in customer data loss from faulty migrations that make it to the App Store (or even just public beta TestFlight).

My understanding is that Atlas helps protect against this by separating schema migrations from the code an LLM would be working with: the LLM would edit schema definitions which have some protection from static types in the application, and Atlas would then generate the schema migrations from the updated definitions. I think you run that migration generation in a CI-like step that would be apart from what the LLM would have access to work with. So there is less risk of the application building and tests working with text fixture data, but having data loss from bad "imperative" migration code.

I don't know about data migrations in Atlas. That could cancel out the above...