61–70 of 79 posts
Interestingly they don't show MySQL benchmarks in the readme; I suspect it might be because the MySQL implementation is pretty basic https://github.com/fastmonkeys/stellar/blob/master/stellar/o...
Line 53 of https://github.com/fastmonkeys/stellar/blob/master/stellar/o... is CREATE TABLE %s.%s LIKE %s.%s This made me think of a table called create table `a; drop table users;` (col int); ... which works in mysql. I don't know if the stellar code will trip over something like this. But mysql (SQL) shouldn't even allow names like that.
Im adding this to my TODO list.
Generally the hardest thing with version control on a database (for an evolving codebase) is separating unrelated changes - such as schema changes vs content updates - and branching and merging those changes in sync with the code dependencies. Another issue is non-destructively replaying development changes into test/production environments. So for example, you might have a feature branch that includes some schema ch…
This sounds like something Sqitch would help with. http://sqitch.org
I have been looking for a tool that will allow me to track, diff and revert changes to the content of specific "business logic" tables so that we can acurately track and test those changes.
It doesn't look like anything like that exists, so eventually I'll have to roll my own.
This sort of thing is useful, but already supported by Postgres through transactional DDL. Migrations that fail will have their transaction reverted.
The use case which this really excites me about is automated testing from the GUI level. If the performance is good enough, this would be really useful for restoring DB state in between tests.
The implications for this extend beyond backing up your database. Imagine a world where daily time-series data can be stored efficiently: This is a lesser known use case, but it works like this: I'm a financial company and I want to store 1000 metrics about a potential customer. Maybe the number of transactions in the past year, the number of defaults, the number of credit cards, etc. Normally I would have to duplica…
Have you looked at Datomic? It seems to fit your problem description well.
Earlier quoted context omitted.
I have regularly used this with database that's nearing 1000 megabytes. I don't particularly mind slow snapshotting because my workflow is more about restoring database back to baseline than taking copies. Please don't use this for production. It is not stable enough and you only end up with lost data.
Why not use a binary backup method? Faster to backup and restore.
I wish projects like these would always include some basic info in their README about: (1) how it works, and (2) how it might fail.
There are only like 700 lines of Python code. Figure it out and submit a pull request to update the README.
An honest update to the README would be to take the whole thing down several notches, if nothing else then to avoid the kind of confusion the post you're replying to expresses.
So, it appears to just copy tables around within the database. I wouldn't want to use this on a DB over a few MB in size. Sure, restores are "fast" (a table rename), but copies are not so much. I can't imagine this would be kind to a production database (lots of cleanup from copied & deleted tables), and would consume a lot more space than a gripped logical backup of the tables in question.
CREATE DATABASE "snapshot" WITH TEMPLATE "source";
INSERT INTO snapshot.table SELECT * FROM source.table;
From the code: INSERT INTO %s.%s SELECT * FROM %s.%s Yeah, good luck with that.