16 posts tagged with "faq"

Question​

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

Answer​

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.

To resolve this issue, you can try the following steps:

1. Add a .gitattributes file to your repository with the following content:

# Ensure all text files use LF line endings
* text=auto eol=lf

2. Commit the .gitattributes file to your repository.
3. If you have existing migration files that were created with different line endings, you may need to normalize them. You can do this by running the following command in your repository:

# Remove all files from the index (but keep them on disk)
git rm --cached -r .
# Re-checkout the files from the repository
git reset --hard

How to detect schema drift in CI and ensure the migration directory is up to date with the desired schema state - ORM, HCL, SQL, or any other schema definition?

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.

Question​

Why does atlas schema apply / atlas schema plan fail with an error like this when working with PostgreSQL extensions?

How can I install Atlas, and why is go install no longer supported?

Given a large database schema, how can I manage schema migration for a single table without affecting the rest of the schema?

Answer​

Atlas supports the --include flag (or the env.include attribute) to scope operations to specific resources. If you need to manage the lifecycle of a single table (or a set of tables), use this flag to avoid changes to the rest of the schema.

For example, to manage the products table in a MySQL database:

atlas schema apply \
  --url "mysql://root:pass@:3308/db" \
  --to "file://schema.sql" \
  --dev-url "docker://mysql/8/dev" \
  --include "products"

If the connection URL is not bound to a schema, specify the schema name in the pattern:

atlas schema apply \
  --url "mysql://root:pass@:3308/" \
  --to "file://schema.sql" \
  --dev-url "docker://mysql/8" \
  --include "db.products"

This command will only apply changes related to the products table, leaving other tables untouched.

atlas schema apply \
  --url "mysql://root:pass@:3308/" \
  --to "file://schema.sql" \
  --dev-url "docker://mysql/8" \
  --include "*.products"

Read more:

• Exclude Tables
• URL Connection Scope
• Declarative Schema Migration

How to inspect an external_schema data source (ORM schema) in atlas.hcl to confirm it loaded correctly?

How can I inspect a specific resource, such as a function, view, or table, using the schema --include flag?

Question​

Why does atlas migrate diff fail with the following error after running atlas migrate apply?

Error: sql/migrate: connected database is not clean: found table "atlas_schema_revisions" in schema <schema_name>. baseline version or allow-dirty is required

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.