Pete Corey
Using Ecto schemas directly in migrations is a huge mistake. I hate my past self for doing it. Every time you modify a schema, all of your past migrations break.
I've since switched to using schema-less queries in migrations, but I'm starting to be of the mind that migrations should just use raw SQL fragments...
clacke
@petecorey A huge mistake, but also a common mistake that probably everyone does once, whether they use Ecto, Alembic or Rails. 😊
Depending on what the language and framework allows, an alternative to not using the ORM at all is to define the required objects locally in the migration.
Rather than resorting to raw SQL I'm still quite in favor of using some abstractions in the application language that can be checked and composed with the usual tools, like the schemaless queries you mentioned.
One big question is *which* SQL. With a little bit of SQLAlchemy in my Alembic migrations I can stay compatible with both SQLite and PostgreSQL, even when using advanced datatypes.
12factors is nice and all, but it's also nice to have an in-memory db for certain integration tests.
Pete Corey
@clacke That's a good point. Dropping down the raw SQL does lock me in to a specific tech unnecessarily. Sticking with schemaless Ecto queries is probably the way to go, I guess!
Pete Corey
@katafrakt Yeah, that’s the root of the problem here. It’s just so convenient! I imagine separating schema and data migrations and relying more heavily on feature switches is probably the most robust way to handle these things.
Jason Axelson :elixir:
@petecorey sometimes I’ll copy a version of the schema as it is at that time directly into the migration module. That way it’s static and won’t change.
Paweł Świątkowski
clacke
@katafrakt @petecorey Fair points. Has someone formulated principles for how a schema migration should look for data migration to be separate?
Some schema migrations are just schema migrations and some data migrations are just data migrations, but often you're migrating the data so that it fits in the new schema.
I suppose it's like decoupling your frontend from your API or your API from your database schema, you'd have to have a concept of versioning, backwards compatibility, deprecation and breaking changes to your schema. So far I have gotten away with treating the API and schema as tightly coupled, the migration making sure they're always in lockstep.
clacke
Daniel Barlow
clacke
@dan Turns out I do want the mapping though, warts and all. =)
SQLAlchemy on Python has enough knobs and dials to overcome the worst of the impedance mismatch, "in particular the 'n loads' problem", and it has a nice clean layer between ORM and SQL abstraction for when you really need to get in there.
The abstraction leaks but is mostly helpful.
Paweł Świątkowski
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.