31–39 of 39 posts
If this is like git, does that mean that you can merge two different branches of data? For instance, if I have two runs of a test, that produce different outputs, can I merge the data back together at the end? If not, then this is only capturing one aspect of git -- the archiving of snapshots of the state of the data.
This looks really cool! A few thoughts: 1. The first thing I thought when I saw this is "How is this secure?". You're wanting to store the most sensitive information a business has - credentials + production DB. I took a look around the site + Google and couldn't find anything about security. Client side encryption of data seems like it would be good to make people comfortable with storing their data at dothub. I'm n…
Thank you for the great feedback! 1. We mention encryption in the docs FAQ https://docs.dotmesh.com/faq/#what-do-you-encrypt -- where did you look for it? Maybe we can make it easier to find. Noted about this being a priority. 2. Thanks for proposing the updated tagline! I'll run it past the team ;-) we'll certainly develop more messaging and use cases around production data as we develop the project beyond 0.1 :-)
I searched on https://dotmesh.com for "security" and "encryption", searched Google for "site:dotmesh.com security", and tried going to http://dotmesh.com/security, but got nothing for all three.
It seems like dot* would have to know about the application logic to show useful diffs, but maybe it can be done generically at the DB level.
If this is like git, does that mean that you can merge two different branches of data? For instance, if I have two runs of a test, that produce different outputs, can I merge the data back together at the end? If not, then this is only capturing one aspect of git -- the archiving of snapshots of the state of the data.
How would you want merge to work?
This is very interesting. Are there any tools provided for "DB diffs"? e.g. show exactly which rows are different between two snapshots? It seems like dot* would have to know about the application logic to show useful diffs, but maybe it can be done generically at the DB level.
We have an issue for this here: https://github.com/dotmesh-io/dotmesh/issues/85
Earlier quoted context omitted.
Relaxo actually grew out of Couch DB. Relaxo used to be a couch query server ( https://github.com/ioquatix/relaxo-query-server - not so useful any more) and ruby front end ( https://github.com/ioquatix/relaxo-model - still useful). But I got frustrated with the direction of couchdb 2.x so I rewrote it to do everything in-process and use git as the document store. It organically grew from that. Unless you are operatin…
Pretty cool. Is there a write up on architecture and usage models? I’d like to see it. I was a happy couch 1.x user, but moved away with 2.0. Nothing specific about it, just needs and timing.
The architecture is super simple, I'd suggest that the first place to look is the source code.
There are really only two ways of accessing the underlying data store - a read-only dataset and a read/write changeset which can be committed.
It's purely a key-value storage at the core - a key being a path and a value being whatever you want.
On top of that you can build more complex things, e.g. https://github.com/ioquatix/relaxo-model which provides relational object storage and basic indexes (e.g. has one, has many, etc)
This sounds really cool way to manage the lifecycle of software. Will try it out. Though my first experience after trying the live hosted tutorial at https://dotmesh.com/try-dotmesh/ "$ dm cluster init dm: command not found"
Did you run the curl command that's the first item in the tutorial?