3 ms·
I've been waiting for someone stepping into the database schema versioning space for years now. Would be very interesting to see how this would work in Veracity
by ojilles 16y ago
I've been waiting for someone stepping into the database schema versioning space for years now. Would be very interesting to see how this would work in Veracity after rolling/maintaining my own solution for years.
And who's this "Vera"? (-:
- tghw 16y agoI may be mistaken, but I don't think that he's talking about database schema migration, but that the VCS itself has a versioned database for any extra meta data that isn't really code, but should go along with it. Mercurial 1.6 added something very similar in a key-value store, although I haven't tried it out yet.
- ojilles 16y ago"Veracity goes beyond versioning of directories and files to provide management of records and fields, with full support for pushing, pulling and merging database changesets, just like source tree changesets." Okay, I re-read that three times, and I still parse that as some form of database versioning (vs. a database where versioning data is stored)... I mean it talks about records and fields, etc. I guess we'll have to wait a bit to see what's supported. On the other hand, tghw's interpretation could be very on the mark as well (e.g. simple meta data that goes alongside the sourcecode).
- ericsink 16y agotghw's interpretation is closer to being correct. A Veracity repo can have lots of DAGs (directed acyclic graphs). A DAG in a repo can either be a "tree dag" or a "database dag". Veracity's notion of a "database" is a model that is unique to Veracity, although its concepts are quite common. Records. Fields. Multiple record types. Simple constraints. Links between records. Simple queries. It's not SQL. Nothing here implies that Veracity will help you, as a database developer on SQL Server or Oracle, manage the versioning of your schema and sprocs and so on. Those are interesting features, but they're distinct from (and a lot higher level than) the stuff I was describing.
- ojilles 16y agoThanks for clarifying!
- igravious 16y agoHi Eric, love your ambitions. Why did you feel the need to put something so database-y right into the repo and go beyond file/directory versioning and key,value tags?
- qaexl 16y agoI am very interested in that "database dag". If it works the way I think it does, I think it will be far more significant than the source control part of the product. For example, I'd like to be able to put together a decentralized knowledge base. Who knows, we may see http://redmonk.com/sogrady/2010/05/04/open-data-github/ http://redmonk.com/sogrady/2010/05/04/open-data-github/ sooner than later.