Comments (7)
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.
Related Issues (20)
- Create database step HOT 5
- Support custom location of createDatabase folder HOT 1
- Extend GrateConfigurationBuilder with folder configuration parsing HOT 1
- Multiple Environments per run HOT 10
- Add "--isuptodate" feature HOT 2
- Migrations keep looping / timeout on permissions scripts on v1.7.0 HOT 13
- Error with Grate 1.7.0 - Read-only file system HOT 3
- Grate internal scripts fail when using CreateDatabase scripts HOT 4
- Upgrade failing for MySQL with syntax error using v1.7.0 HOT 8
- Suppressing logging of internal grate migrations doesn't appear to be working correctly HOT 3
- Scripts in internal Grate migration tables are always registered as "run" HOT 3
- --drop without continuing migration use case HOT 1
- Create database fails when an empty createDatabase folder is present
- Should CONTRIBUTING.md be updated to list .NET 8 HOT 2
- runAfterCreateDatabase are run even if database isn't created from scratch by grate HOT 3
- GrateScritpsRun everytime i run the tool HOT 2
- Question - How to mark one-time migration as run HOT 3
- Doesn't work on console app NET 8 using grate.sqlserver HOT 1
- Running Grate on RoundhousE database - all scripts are new HOT 8
- Baseline creates orphan version_id in ScriptsRun HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grate.