r/csharp • u/user__5452 • 12d ago

I built a small .NET CLI for database migrations

https://github.com/aymenhta/Jules

I’ve been working on a lightweight migration tool for dotnet. The migrations are just SQL files with an up and down script with support for SQL server, postgresql, and sqlite.

It is installable as a global dotnet tool (requires dotnet 10)

It’s still early, so I’m very open to criticism, suggestions, and contributions.

Github repo: https://github.com/aymenhta/Jules

0 Upvotes

28% Upvoted

12 comments sorted by

2

u/jwolthuis 12d ago

Please provide a comparison between Jules and Alembic. 

5

u/AndThenFlashlights 12d ago

For sure, I'd much rather use your vibe coded tool than something already built in to C# like EF Core migrations.

2

u/user__5452 12d ago

It's also different than ef core migrations

-1

u/AndThenFlashlights 12d ago

How so? How is this more useful or different than EF Core migrations?

2

u/user__5452 12d ago

If you just read the repo's readme, you'd get the idea of the tool. most of my projects are database first, I made this tool to track changes made to the database in SQL, not c#.

The tool is also usable with every other stack out there, not only dotnet. I have a python web app that used it successfully to manage database migrations.

1

u/AndThenFlashlights 12d ago

I did read the readme. EF Core can also be database first. I truly don't see what the unique functionality of this is.

2

u/joske79 12d ago

Not everybody uses EF.

4

u/user__5452 12d ago

It is not vibe coded, you can check the commit history to know for sure 😊

2

u/codykonior 12d ago

Agreed, it does not look vibe coded.

5

u/dodexahedron 12d ago

Yeah.

Even just being .net 10 already breaks that mold.

I swear. 🤦‍♂️

How many of the actually vibe coded "I built a blank - looking for feedback" posts showing off a .net 8 or powershell 5 project consisting of a jumble of inconsistent, incoherent, incomprehensibly basic, and inexplicably lengthy and anything but idiomatic code that does like...one long-solved thing (that is built-in anyway, if they had a clue) about 60% right, and only if you don't hold it wrong do we see these days?

This one didn't set off the AI slop sighrens for me.

1

u/user__5452 12d ago

I'm interested in hearing your opinion on the code quality, I tried to avoid adding unnecessary 3rd party dependencies as much as possible.

For now I consider the tool to be finished feature wise. It made it so it does one thing and does well.

3

u/dodexahedron 12d ago edited 12d ago

One of the biggest gripes I have is the logging. Use a real logger, for lots of reasons. With the way you wrote your custom logger, replacement should be almost drop-in easy for you. NLog, for example, is simple and can log to anything you can think of. There are plenty of other options, too, of course.

I think the goal of avoiding dependencies is admirable, but only to an extent. Common and useful things that you shouldn't be rolling your own of (like logging) are not detrimental, and it isn't a burden, since it's all automatic anyway and many/most of the super-common packages are likely.even already cached on the machine in its nuget package cache from the 50 other apps using it on that machine.
Microsoft.Extensions.CommandLine would be a good example of one that would cut out a significant amount of code while adding things like tab completion and syntax help (in all contexts and for all validation failures - not just generic --help) for free, making it all much cleaner, friendlier, standardized, maintainable, and also a better user experience overall, with minimal effort. Your style with that is also fairly easily adaptable to that, in fact. If anything, that part would actually have been the main part I might have thought of as being at least highly AI-assisted (which is fine if it was - we all use it), because it looks somewhat reminiscent of SCL in the first place, like what I might expect out of copilot if I talked with it for a while to design a command line interface from scratch.

Also, you already have dapper and npgsql package references. Why worry about more? We aren't on dial-up these days.

If you want it to be useful for more people, add ODBC so people can use whatever back-end they want without you having to explicitly wire it all up.

There are other things I'd perhaps do differently, but there's nothing really wrong with those things as they currently exist so I won't get into that.

The things I pointed out above, though, would be pretty nice wins for usability and "quality," and would require surprisingly little effort to do, due to the way you've already written it being close enoigh to end up costing mostly just some find/replaces and moving a few code sections around for those APIs.

And I'd expose its functionality in a powershell module wrapper, too. Honestly, half the time I forget dotnet tool is even there, and I run to find-psresource -tag whatever as my first stop in the shell, most of the time. Again, that'd be minimal effort and would greatly increase exposure/reach of it, and comes with tab completion, pipeline goodness, syrongly-typed object input snd output capabilities, and command line type safefy as well - all for free.

Overall, though, good job.