4 ms·

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-devel

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.

wutXthree 6y ago
>they can easily make breaking changes this can be mitigated with roll-back scripts
- inssein 6y ago
  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).
- dspillett 6y ago
  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.
inssein 6y ago
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.
- cloudking 6y ago
  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!
  - ineedasername 6y ago
    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?
lakshmibaskaran 6y ago
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.

wutXthree 6y ago

>they can easily make breaking changes this can be mitigated with roll-back scripts

inssein 6y ago
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).
dspillett 6y ago
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.

inssein 6y ago

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.

cloudking 6y ago
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!
- ineedasername 6y ago
  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?

lakshmibaskaran 6y ago

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.