GitHub: https://github.com/saward/spawn

Docs: https://docs.spawn.dev/

Shout out to minijinja (https://docs.rs/minijinja/latest/minijinja/) which has made a lot of the awesomeness possible!

Some features (PostgreSQL via psql only for now):

- Store functions/views/data in separate files

- Git diff shows exactly what changed in a function in new migrations

- Easy writing of tests for functions/views/triggers

- Env specific variables, so migrations apply test data to dev/local db targets only

- Generate data from JSON files

- Macros for easily generating repeatable SQL, and other cool tricks (e.g., view tear-down and re-create)

I started this project around two years ago. Finally have been able to get it to an MVP state I am happy with. I love using PostgreSQL and all its features, but current available tooling makes utilising some of those features more challenging

I created spawn to solve my own personal pain points. The main one was, how to manage updates for things like views and functions? There's a few challenges (and spawn doesn't solve all), but the main one was creating and reviewing the migration. The typical (without spawn) approach is one of:

1. Copy function into new migration and edit. This makes PR reviews hard because all you see is a big blob of new changes.

2. Repeatable migrations. This breaks old migrations when building from scratch, if those migrations depend on DDL or DML from repeatable migrations.

3. Sqitch rework. Works, but is a bit cumbersome overall with the DAG, and I hit limitations with sqitch's variables support (and Perl) for other things I wanted to do.

Spawn is my attempt to solve this, along with an easy (single binary) way to write and run tests. You:

- Store view or function in its own separate file.

- Include it in your migration with a template (e.g., {% include "functions/hello.sql" %})

- Build migration to see the final SQL, or apply to database.

- Pin migration to forever lock it to the component as it is now. This is very similar to 'git commit', allowing the old migration to run the same as when it was first created, even if you later change functions/hello.sql.

- Update the function later by editing functions/hello.sql in place and importing it into your new migration. Git diff shows exactly what changed in hello.sql.

Please check it out, let me know what you think, and hopefully it's as useful for you as it has been for me. Thanks!

(AI disclosure: around 90% of non-test code by me, AI was used more once the core architecture was in place, and for assisting in generating docs)

Comments URL: https://news.ycombinator.com/item?id=47055579

Points: 1

# Comments: 0

If the code I was writing was, say, small websites all the time for different clients, I can see it being a big improvement. But iterating on a complex existing platform, I’m not so sure that AI will keep the system designed in a maintainable and good way.

But if your experience is with the same sort of code as me, then I may have to re evaluate my judgments.

I've said the same thing as you, that there is a LOT left to be done with current AI capabilities, and we've barely scratched the surface.

- Type of dev work (infra, frontend, backend, etc)

- Programming language

- Level of experience

- Quality expectations of project/work environment

I am playing with Zed now though, and it has a "subtle" mode for suggestions which is great. When I explicitly want to see them, I press option key. Otherwise, I don't see them.

And that's not just because its output is often not the best, but also because by doing it myself it causes me to think deeply about the problem, come up with a better solution that considers edge cases. Furthermore, it gives me knowledge in my head about that project that helps me for the next change.

I see comments here where people seem to have eliminated almost all of their dev work, and it makes me wonder what I'm doing wrong.

Although tbh, even in the worse case I think I am still faster at reviewing than writing. The only difference is though, those reviews will never have had the same depth of thought and consideration as when I write the code myself. So reviews are quicker, but also less thorough/robust than writing for me.

For harder problems, my experience is that it falls over, although I haven't been refining my LLM skills as much as some do. It seems that the bigger the project, the more it integrates with other things, the worse AI is. And moreover, for those tasks it's important for me or a human to do it because (a) we think about edge cases while we work through the problem intellectually, and (b) it gives us a deep understanding of the system.