3 ms·
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that. It has a syntax of your expectations, functionally existing as
by kristopolous 2y ago
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that.
It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.
For instance, pretend I'm ok with mv being able to clobber except in some special directory, let's call it .bitcoin or whatever. (chattr can also solve this, it's just an example). The tool can be implemented relying on things like bpf or preload
Originally I wanted it as a SQL directive ... a way to safeguard a query against doing like `update table set field=value expect rows=1` where you meant to put in the where clause but instead blew away an entire column. I think this would be especially useful surfacing it in frameworks and ORMs some of which make these accidents a bit too easy.
- danielheath 2y agoFor sql specifically, “limit 2” is my default way to write “expect 1”; if it affects two rows, I know that I have screwed up, whereas “limit 1” can be wrong without my noticing.
- kristopolous 2y agoThat's not a terrible solution although expect sounds like a simple safety mechanism for feeble-minded people like me who do simple queries. I actually know postgres people. I should probably ask them
- kragen 2y agojust to clarify, this has nothing to do with the "expect" that is the other major application of tcl other than tk?
- kristopolous 2y agoNone. I was just reminded of a good idea I never implemented
- progmetaldev 2y agoWhen it comes to SQL, I will often write a SELECT with very explicit search (WHERE) criteria for this very reason. Then copying that statement, commenting the original, and pasting to change into an UPDATE or DELETE statement seems to be a technique that works well for me. The SELECT tells me exactly what I'm going to UPDATE or DELETE, and once I have that, changing the syntax is very minimal. In the case of an ORM, you might have to write a tool that only listens on LOCALHOST to run these statements first.
- kristopolous 2y agoI always write the where first. It's kinda like thinking in RPN or postfix. I put the parts in out of order in a way that prioritizes the minimization of error. But this is stupid. These are computers, we can make whatever we want. Executing a delete or update should, if one desires, not have to be database knifeplay.
- progmetaldev 2y agoI know what you mean, I do the same. I agree, but at the same time, it's difficult to start building in protections for the user. Where do you start and where do you stop? I have been forced to do the extreme to protect the user, and then you are asked why things are so difficult to use. I think to make something for someone that concentrates in the technology, as well as a beginner, means you've got to give up so much power (or create a secondary syntax/interface for both audiences). It would be nice to be able to set modes, but then it's going to be database specific unless it has proven itself to be useful across engines. Like most standardization, then you play syntax games between vendors. It would be nice to at least be able to write an UPDATE or DELETE statement with a leading character or keyword to display affected rows.
- kristopolous 2y agoIt's completely Optional safeguards. Add long as it's optional, I advocate for having as many of those as people can imagine
- x-shadowban 2y agoOh yeah, re: SQL expect - I always wish joins had a "cardinality assertion", like a regex *?+ (or ! for exactly one)