Inspect an external schema data source (ORM schema)
How to inspect an external_schema data source (ORM schema) in atlas.hcl to confirm it loaded correctly?
How to inspect an external_schema data source (ORM schema) in atlas.hcl to confirm it loaded correctly?
What encoding is used by Atlas for schema files? How do you avoid encoding issues with PowerShell on Windows?
Atlas uses UTF-8 to encode schema files and migration files generated by Atlas. UTF-8 is the default encoding on nearly all system terminals, but on Windows, PowerShell uses UTF-16 by default. This can cause an encoding issue when Atlas loads the schema files generated by the inspect command.
When working with multiple branches and applying hotfixes directly to production, out-of-order migration conflicts may occur if migration files are created with timestamps that don't reflect the actual merge order.
Consider this scenario:
Initial state:
001_initial.sql001_initial.sql002_add_posts.sql004_add_index.sqlAfter hotfix applied directly to production:
001_initial.sql003_hotfix_add_email.sql ← hotfix added001_initial.sql002_add_posts.sql004_add_index.sql
After merging master into dev - the problem:
001_initial.sql - Applied to production002_add_posts.sql - Dev-only, not applied to production003_hotfix_add_email.sql - Applied to production004_add_index.sql - Dev-only, not applied to productionThis creates a non-linear migration history where migration files 002 and 004 were created before and after the hotfix timestamp but haven't been applied to production.
When using Atlas on my macOS, I can run atlas migrate apply without any issues, and it applies the migrations successfully.
But when running in CI on linux, I get the following error: Error: checksum mismatch
This issue is likely due to differences in line endings between operating systems. macOS uses LF (Line Feed) for line endings,
while Windows uses CRLF (Carriage Return + Line Feed). When you run Atlas commands in a Docker container,
it may be using a different line ending format than what your migrations were created with.
In version control systems like Git, a changeset represents an atomic unit of change. It groups related file modifications under a single hash, allowing them to be reviewed, applied, or reverted together.
In database migrations, a changeset is a unit of schema or data changes made up of SQL statements stored in a migration file, typically executed together in a single transaction.
With Atlas, we advocate for treating migration directories as deployment artifacts resulting from a structured build process. The preferred approach is to push migration directories to the Atlas Schema Registry. In addition to its role as a migration directory storage, the Schema Registry provides a tight integration with the Atlas CLI and the Atlas Cloud UI, allowing you to deploy migrations, visualize schemas over time, review deployment logs and errors, and more.
However, some users prefer to store their migration directories in S3, typically due to internal policies or requirements.
Why does atlas schema apply / atlas schema plan fail with an error like this when working with PostgreSQL extensions?
Error: create extension "postgis_topology": pq: extension "postgis_topology" has no installation script nor update path for version "3.4.3"
How can I inspect a specific resource, such as a function, view, or table, using the schema --include flag?
Developers who use Atlas to run migrations using a golang-migrate directory format, may run into an errors like:
-- migrating version 20250324061649.down.sql
-> DROP TABLE `users`;
Error 1051 (42S02): Unknown table 'public.users'
How do I populate my databases with a static dataset using Atlas?