Hi JPatrick, yes, now its much more clearer to me and I see that this is definitely a usefull thing for ArangoDB users.
I've send you a PR with some tiny updates to the readme, feel Free to merge or decline ;-) While I now see that you didn't choose yaml for the reason of limiting dependencies, I'd like to explain my question a bit more. Comming from an environment where Apache JMeter was used for QA & load tests, you have a nice & snappy UI where you can click your http requests together with a nice UI. However, jmeters storage backend is writing XML files. If you now want to do code reviews on change sets, thats next to impossible - the XML is hardly as readable as binary. My company back then developed YAML based testcases on top of TheGrinder, which overcame all these limits in a very nice way, plus developers really enjoyed working with it. Since one may want to do code reviews on schema evolution descriptions, I would sugest that you (similar as Liquibase) at least offer a way to have yaml support on top of the current implementation. One similar tool in the ArangoDB stack is swagger.io - which has a json (as not human readable) representation of its REST grammer; If you load it in the swagger editor ( http://swagger.io/swagger-editor/ ), it offers you a YAML representation that is more compact and offers a better overview for the reader. So, maybe a derived Migrant Verde, that has the additional YAML dependency could offer better user experience, plus maintain the XML schema being easily portable to YAML? Cheers, Willi PS: maybe you could think about a little less explicit language in the README? On Saturday, July 9, 2016 at 6:19:05 AM UTC+2, JPatrick Davenport wrote: > > Sorry for the delay. Had somethings to take care of. > > I've updated the README. For those watching here, Migrant Verde is a > schema evolution tool. It supports embedded and command line execution. > This means that a Java/JVM application can use it directly and a Python or > Ruby app can shell out. > > The goal is to automate the process of database lifecycle management. If > you have a new developer, the library enables creating a prod mirror > locally when the application boots the first time. It allows you to manage > your DB changes in source control without having to invent your own > migration scheme. Ultimately it aims to be Liquibase for ArangoDB. > > I'd be happy work with the Arango team on a blog post. At present a person > has to clone the repo and build the jar manually. I'm working on getting a > maven central account setup. I'll follow up here when that's done. > > To the rest of the community, > If you don't mind the annoyance of having to build the project before > using it, please kick the tires. Hopefully it helps out. If you want to add > features like configuring a collection at creation time, please submit a > pull request. We've got limited resources so we focus on our immediate > needs. > > Thanks, > JPD > -- You received this message because you are subscribed to the Google Groups "ArangoDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
