At my workplace, the command-line database tool (which is essentially just a wrapper around the standard MySQL CLI) connects with a read-only role by default, and you need to explicitly pass a flag to it to connect with a read-write role. The two roles use separate ACLs so we can grant someone just read-only access if they don’t need write access.
Also my database tool (the one built into pycharm) warns and requires you to hit submit a second time if you try a delete or update without a where. Discovered this on local where I really did want to update every record, but it’s a good setting.
Oh there was plenty of blame to go around. I wasn’t exactly fresh out of school either. I had “extensive experience with SQL Server” on my resume by then.
That’s the employer’s fault for making it so easy to connect to prod with read-write permissions. Not your fault.
At my last job I was given write permissions to production and I asked for read only credentials instead, I know my own stupidity
At my workplace, the command-line database tool (which is essentially just a wrapper around the standard MySQL CLI) connects with a read-only role by default, and you need to explicitly pass a flag to it to connect with a read-write role. The two roles use separate ACLs so we can grant someone just read-only access if they don’t need write access.
+1
We have read only access.
Also transactions are good ideas.
Also my database tool (the one built into pycharm) warns and requires you to hit submit a second time if you try a delete or update without a where. Discovered this on local where I really did want to update every record, but it’s a good setting.
Look at mister fancy pants over here with a database tool. Back in my time we had to use Query Analyzer uphill both ways.
Oh there was plenty of blame to go around. I wasn’t exactly fresh out of school either. I had “extensive experience with SQL Server” on my resume by then.