rotemtam

cool project. i built something similar but for the terminal side — virtui (https://github.com/honeybadge-labs/virtui).

it lets agents drive terminal apps via pty, take screenshots, send keystrokes, and record everything as asciicast.

basically the same idea as proofshot but for tui/cli apps instead of browser ui. been using it to have agents prove their work actually when submitting prs.

such a neutral headline for "data center bombed by terrorist regime"

Genius !!

Thanks for the mention evan!

I only trust chords that came from Oren Mustakis big PDF book for shira betzibur.

Anyways, who is here is the bogeret

great question. i am no expert on the topic, and my weekend project ended up being pretty small (a few hundred LoCs in total). I was able to get the core logic "work function" to work, but all of the stuff around it, I wrote by hand.

Hello HN!

@thunderbong thanks for posting.

Blogpost author here, happy to answer questions if any exist

Well done!

Thanks for sharing this. Had a great time presenting this at our local Gophercon.

Happy to answer any question here if there are

Hey thunderbong,

Thanks for posting this - I am the author of the blog post, so I'm available to answer any question!

Hey,

I'm @a8m's co-founder and also a maintainer of Atlas. I don't have an exact feature comparision but Atlas (and esp the Postgres driver) are heavily maintained with advanced features like views and materialized views (functions and procedures coming up, followed by triggers and more).

What features specifically are you missing in migra? Perhaps we can prioritize them. Also feel free to join our Discord https://discord.gg/zZ6sWVg6NT

Thanks for the mention of Atlas <3

Hello fellow hackers

Happy to share this announcement of the latest version of Atlas, our open-source schema management tool.

With this version, Atlas gets first-class support for SQL for defining the desired state of the database.

Think of it like "terraform apply" for your MySQL/Postgres/etc. Previously your schema needed to be define in an HCL syntax we maintain, now you can use plain ol' SQL!

Will appreciate feedback and comments! Rotem, co-creator of Atlas

Thanks for the kind words, Ivan! You're awesome

Thanks so much for the kind words.

Join us on our discord server (https://discord.gg/qZmPgTE6RX) to share what you're working on!

Hey @thunderbong

One of Ent's maintainers here. Thanks a lot for sharing our project.

To all others interested, Ariel (a8m) and I are here following this thread, so feel free to ask us anything and everything!

In this post, we will demonstrate how to create a basic configuration language using HCL and Go. To make this discussion entertaining, let's imagine that we are creating a new PaC (Pizza-as-Code) product that lets users define their pizza in simple HCL-based configuration files and send them as orders to their nearby pizza place.

Who doesn't love pizza?

Hey gravypod! Thanks for writing. Indeed we built the schemaspec implementation so that it’s definitely possible to use other syntaxes to define schemas. HCL was chosen for various reasons to be first but we are planning on supporting others

Hey bitspook! One of Atlas’s creators here. Thanks for sharing this!

You describe the existing state well. Atlas can currently be used to perform what we call declarative database migrations.

This is great for many use cases. But it will not do for others, for a few reasons .

First, there are many ways to get from point A to point B. The classic example is a table rename. To get from the existing to the desired state, we can either ALTER TABLE or DROP and CREATE it. What did the user mean? Second, migrations are a very sensitive operation that can easily result in an outage if done wrong. Therefore, many companies check each migration into source control and have it reviewed in CR, and perform different quality and safety assessments on it.

Therefore, while “terraform for DBs” sounds great, it’s not enough. In the next versions of Atlas, we’re rolling out a different workflow that we call migration authoring or “versioned migrations” that address these issues in a very cool way that I hope many will view as useful.

Happy to answer any questions! R

Hi daenney

(One of Atlas's creators here)

Thanks a lot for the feedback.

Frankly, we didn't make the Terraform analogy. We didn't even start this thread, just woke up to this wonderful discussion this morning :-) With regards to our marketing material, we only state that our DDL is terraform like because it is based on HCL..

I completely hear you on Terraform and it's pains and I've had my fair share of problems with it myself! This is why our approach to building Atlas is to offer two styles of migrations: declarative migrations (which is what you're seeing now) and a more advanced workflow (which I believe most mature projects will end up using) which we call migration authoring or versioned migrations.

This second approach is similar to existing migration tools, with versioned SQL files, up/down direction, etc. In fact, it will work great out of the box with most existing migration tools (such as Flyway, Liquibase etc.) The main difference is that users will be able to use Atlas's fairly advanced migration planner and more advanced features that will be available later this year.

So indeed, we're not a terraform for X, though i'm sure that title by whoever chose it brought this topic quite a bit of attention :-)

hey redact207 Thanks for the feedback! (one of Atlas's creators here).

First of all, I completely understand you. Good ol' SQL has been with us for decades and isn't going anywhere. In the very near future you will be able to work with Atlas in pure SQL in a few ways: 1. Use a command like `atlas schema diff` (API not final) to generate the diff SQL for you, that you can then edit and use with your favorite tools. 2. Use a CREATE TABLE statement instead of HCL for your desired schema. 3. Use Atlas with a workflow that we call "migration authoring" to author for your the migrations into your <favorite migration tool> directory format.

Second, I'd say that as much as I'd like it to be ubiquitous knowledge, many product teams don't have anyone on board with expertise like you probably have in planning migrations well, and so they can benefit greatly from a tool that will embed well tested and researched "DBA" knowledge into migration planning. The amount of outages I've heard about that are related to migrations that were ill planned is enormous.

Many have commented on this thread that it's a huge topic with a lot of subtleties and that it will be very hard to build a tool that does this well. I agree with that sentiment, but we built a strong team here at Ariga, and I hope together with the OSS community we will build something remarkable.

hey, Yes, indeed that's part of our plan!

If you want to chat about it, join us on our discord server? https://discord.com/invite/QhsmBAWzrC

Hey!

Sure, we'd love that :-)

Ping us on our Atlas discord?

https://discord.com/invite/QhsmBAWzrC

Hi parhamn,

One of Atlas's creators here.

To be precise, we never analogized Atlas to Terraform :-) We said the existing HCL DDL is terraform like (which it is).

As far as I know, there are no heavily used terraform plugins for handling database migrations - and not because it's not possible.

The CLI currently exposes a declarative workflow (atlas schema apply), but we our analysis of the problem is that that declarative is not robust enough for many projects. For this reason, the Go API already support "versioned migrations" or "migration authoring" which means Atlas will generate migration files (SQL) and maintain the directory for you in the format that you like (Flyway, go-migrate etc).

In the very near future we will publish the migration authoring functionality to the CLI (you can already play with it via the Go package if you like).

Hi ngouto, One of Atlas's creators here.

Indeed it is. We founded Ariga (the company that's maintaining Atlas) to build this kind of infrastructure which we feel is missing from the data infra/platform engineering landscape. Aside from our existing love for open-source (we maintain https://entgo.io), we are building Atlas in the open because we understand the scope of the problem and it's long-tail characteristics and realize that it will have to be a community effort.

Hi manigandham!

One of Atlas's creators here. Thanks for the feedback!

I completely understand your point here, and I would add that for many use cases the declarative approach isn't robust enough for schema migrations. The classic example being, how does a tool discern between a column drop/add and a rename, and how does the migration tool allow for backward-compatible schema evolution?

For this reason, as you can see on https://atlasgo.io, we are going to publish to the CLI a different style of migration which we call "versioned migrations", that support the process of "migration authoring". This already exists in the Go API so if you want to delve into it on your own you can, but it will be out as part of the CLI really soon.

Migration authoring means that you modify your desired schema, and the tool generates a possible migration for you. In cases where there is ambiguity (multiple ways to reach state B from A), the tool may interactively prompt you for decisions.

So hopefully with Atlas you can get the best of both ways. Have an intelligent engine help you author the migration for you, but ultimately you get an SQL file you can edit, review in CR, and use your existing migration tools with (Flyway, Liquibase, etc.)

Feel free to join our discord channel (https://discord.com/invite/QhsmBAWzrC) if you want to chat more :-)

R