Add support for `--drop` ? about grate HOT 7 CLOSED

I think aiming to be as compatible as possible is the right path, but am happy to leave little used/problematic features behind in order to make maintenance easier... If we differ to RoundhousE in some way, but provide clear docco on how to upgrade then I personally think that's a good trade off.

from grate.

think that this is a good idea by the way...

from grate.

I love that we create issues for each separate additions. I've never used "drop" myself in RoundhousE. The semantics are basically run "DROP DATABASE " before running the migration? Or is there any more to it?

from grate.

In RoundhousE it effectively just runs DROP DATABASE, and then terminates... from the help:

--drop | Drop - This instructs RH to remove a database and not run migration scripts. Defaults to false.

I could see an argument for dropping and then running like normal as that's the only scenario I've ever used it for, but that opens up the discussion around backwards compatibility.

It could also be another Command (with the default RootCommand effectively being "migrate", ie grate migrate [params] by default, and grate drop [params] for this? Again a slight back compat change there losing support for the --drop syntax.

I love that we create issues for each separate additions.

I've found a few rough edges for my scenarios already but this is generally much further along than I expected, well done! Would it be a good idea for us to add simple (title only?) issues into here for the things that aren't working for our current scenarios and set that as a sort of MVP for grate, with as much other missing RoundhousE functionality coming along later?

from grate.

Ah, I see. The drop shouldn't be too much effort then, I think. Just expand the ISyntax interface, perhaps, and implement using it ;)

When I started out, I aimed for 100% compatibility, switch/parameter for parameter with RoundhousE, but I don't know if that should be a goal. And, I like the idea of using different Commands. I think it's more system.commandline-esque, and similar to the way other tools as dotnet run, dotnet build, etc, work.

I am all for creating placeholder issues for missing features. It makes managing them much easier!! And, then we can plan them, and aim for an MVP in a not-too-distant future. I think getting some runnable bits out there, and opening up the repo to the public as soon as possible should be a goal. I have of course bought the grate.dev domain long ago :D (first things first), so writing documentation, maybe in github pages, is a good place to get going as well.

from grate.

I agree. So, if using Command makes sense for some, I think we should. There are a few other "main modi operandii" of RoundhousE too, there is a 'baseline', I think, are there more? I haven't used them.

Here they are: https://github.com/chucknorris/roundhouse/wiki/RoundhousEModes

from grate.

I don't use baseline much but have done so occasionally in the past (when changing source control systems and a change in line terminators broke our hashes... that was the driver behind the line terminator fixes in RoundhousE I think).

I'm getting some files in an existing project reporting as changing under grate when it looks at the RoundhousE schema so if I can't find an obvious bug there a baseline mode in grate to reset the hashes as part of an upgrade away from RoundhousE may be useful 👍

from grate.