Hacker News Reader

Comment by cloudking | Hacker News Reader

It looks like your goal is to enable non-developers in an organization to make changes to a production database?

If so, you may want to consider that non-developers typically don't have access to production databases for a good reason: they can easily make breaking changes.

You may want to consider creating a "pull request" type functionality where a non-developer can create a change, and instead of having it executed immediately, be sent to a developer/reviewer for review and approval. This would still save developers time in crafting complex SQL queries, instead focusing on reviewing the changes others are proposing and ensuring they don't break the system.

View on HN

That is exactly my early goal.

Currently, the column based access should help limit modifications to only specific columns. That said, I have heard this feedback and definitely have started thinking about an approval / pull request based workflow.

For some more context, when I worked at a large organization, any manual changes that were being made via SQL commands or CLI commands were sent through our code review system first.. and these were being done by developers. So by enabling a similar paradigm with a UX for non-developers, I think you're on to something here, good luck!

The problem you described at.that organization could have been solved with a policy change though. No need for a new SaaS product.

And if the policy didn't change, this product wouldn't help: Why would they have let people make immediate changes via web interface if things were so tightly locked down?

Does this not limit the speed and agility at which some organizations operate? Non developers should only be granted access to the tables that does not lead to a breaking change.

>they can easily make breaking changes

this can be mitigated with roll-back scripts

In many organisations, a break in a system holding production data is serious even if it isn't a serious break, so being able to roll back or otherwise undo would not cut it.

Much better would be to give them a replica to work on and a change confirmation process that allows signed-off changes to be pushed into production.

As another idea, since all the changes are described in an AST, I could offer a "undo" in the query log for INSERT action. The UPDATE action would require a bit more work as I don't track the previous data (and it could be changed in another system as well).

Reply on news.ycombinator.com