351–360 of 514 posts
Don't ask me why the linter configurations weren't simply persisted in git.
I've been a software dev since the 90s and at this point, I've learned to basically do things like audit trails and soft deletion by default, unless there's some reason not to. Somebody always wants to undelete something, or examine it to see why it was deleted, or see who changed something, or blah blah blah. It helps the business, it helps you as developer by giving you debug information as well as helping you to c…
> Somebody always wants to undelete something
> or examine it to see why it was deleted
> or see who changed something, or blah blah blah
It's a mysql-compat database that is versioned and forkable - basically imagine git and mysql had a baby. Every transaction creates an entry in the commit log that lets you see when, how, and why the database changed. And just like git you can `dolt checkout ` to see what the data was like at some point in time, or `dolt checkout -b temp-branch ` to make exploratory changes to some historical version, or `dolt revert` to revert a transaction... etc.
There is a lot more power that comes with making the entire database versioned and forkable by default. For example it makes it much easier to recover from catastrophic bad code pushes, etc.
note: Dolt was forked from Noms, my previous project, but I don't work for Dolt or have a stake. Just a fan.
There's a very legitimate case that I've seen made for soft-deletion in several different situations: foreign keys related to "created-by" columns. Hard-deleting a user who created an object that remains in use after they're gone would trigger referential integrity complaints on those columns. Without being able to reference a "deactivated" user's primary key in such a situation, you'd have to come up with some count…
There are Rails gems that can handle this in various ways. But the easiest way is to deactivate the user account (is_active boolean) and continue to reference the user in internal records.
However, if you DONT use an active/deleted flag, and instead do what the author suggests, I dont know the right way to support deleting said user
If you set the deleted_record table as part of a trigger on delete of other tables, you could turn on cascading delete and hope for the best. Outside of that I dont have any plan for using this with referential integrty.
It would be easy enough if you decided NOT to use referential integrity, but then you save the space of ONE user record and retain how many orphan records, making them all effectively soft deleted anyways... whats the point?
Quoted post unavailable.
Then have a statement like RESTORE * FROM ...
Earlier quoted context omitted.
Sorry!
I think lawyers probably miss a lot of these technicalities (which explains why they can require something as technically unreasonable as Schrems II), but I just wonder if someone more technical can actually push for something like that, to win themselves some questionable points, in the name of improving privacy.
Earlier quoted context omitted.
> Nor can anyone call up previous employer and require them to delete all the work they ever did from their company’s computer systems. You can’t delete IP as this is not covered by GDPR, but you sure can ask them to delete your identification data from their records as GDPR also works for employees not just customers. It’s a problem with for example vcs. Unless there’s another law in ruling, GDPR is the baseline. It…
>You can’t delete IP as this is not covered by GDPR, but you sure can ask them to delete your identification data from their records as GDPR also works for employees not just customers. You can ask , but the right to have data erased is not an absolute right. In fact there's an enumerated list of the circumstances in which the data must be deleted but data controllers are otherwise under no specific obligation to del…