4 ms·

How do you keep track of dirty writes on structs? I want to only persist if the struct was actually changed. I could add getters setters, but a lot of the Go co

How do you keep track of dirty writes on structs? I want to only persist if the struct was actually changed. I could add getters setters, but a lot of the Go community seems to say I’m stupid for wanting to do that. I could track externally from the strict, but that seems backwards.

weberc2 8y ago
Can you elaborate for someone who doesn't know what "keeping track of dirty writes on structs" is for?
- randomdata 8y ago
  He mentions persistence. Probably for use in an ORM-like fashion, where only the table columns that have changed are to be updated.
- PavlovsCat 8y ago
  https://en.wikipedia.org/wiki/Persistence_(computer_science)#Dirty_writes https://en.wikipedia.org/wiki/Persistence_(computer_science)... I first heard of that in context of writing to the screen, actually, when you don't want to redraw all the things every frame, or simply can't afford to, and only draw the things that have changed (i.e. are "dirty"). So if you were to keep track of the old position of an object, you might redraw the area of background where that object was, and then just draw the object at the new position, instead of drawing the background for the whole screen, and then the object. Browsers are also kinda heavy on this when it comes to both layout and drawing. E.g. when the content of a div with fixed size changes, you only have to layout and draw the text in the div -- but if the size isn't fixed, you might relayout and redraw everything on the page that follows the div, but might not need to touch anything that comes before it. I'm sure it's incredibly complex, but still much faster than not doing it.
- virmundi 8y ago
  Sure. I have a Profile. Let's say I load it from the database and make a change. I want to know if I need to save the profile. This is particularly important when using optimistic locking, a.k.a. resource versioning. My profile has a version number, like an ETag. I only want to update if there is a real change, and updating increases that revision number with every persist. Here's a scenario. A woman gets married. Her last name changes. She updates the profile from Smith to Jones. The last name is now dirty. The code that save the object can say, "Are you dirty?" The struct says, "Yup". Saving code says, "Right! In you go." On the other side, the bit gets flipped back to false (it's cleaned). At the end, the revision updates by one and goes back to the client. Another scenario. A user opens the edit profile box, doesn't change anything, but hits save. Without a dirty check, the object, which hasn't fundamentally change, gets saved with a new revision number. Now what is all this about the revision number? I don't want to allow changes to a profile whose revision number is greater than the revision number my client passes. Let's say the Profile has revision 5. The client, which has been disconnected for a bit, says, "Update the profile, at revision 2, with all this new great data." The system needs to reject that update. The client needs to tell the user, "Sorry. That didn't work. Here's all this new data." If the client is especially Canadian, it will also say, "Oh, by the way we've saved your data, would you like us to copy it over the new data". I've never seen Canadian code, and mine is especially Floridian, but it could happen like that. All of this is fairly easy in OO languages, which Go is not. It's actually easy in Go too if you use -ters and Setters (Go doesn't like GetFirstName(), but is okay with FirstName()). If I use functions attached to structs, easy. Just curious how other feel about this.
  - vthallam 8y ago
    We use functions on the struct. I know it's not ideal but just works for us.
rpeden 8y ago
Maybe store a hash of the values in the struct and check against that too see if anything has changed? If you're doing lots of dirty checks, that might be too resource intensive, though. Or just use getters and setters and if anyone calls you stupid, ask them to demonstrate a better solution that still solves your problem.

weberc2 8y ago

Can you elaborate for someone who doesn't know what "keeping track of dirty writes on structs" is for?

randomdata 8y ago
He mentions persistence. Probably for use in an ORM-like fashion, where only the table columns that have changed are to be updated.
PavlovsCat 8y ago
https://en.wikipedia.org/wiki/Persistence_(computer_science)#Dirty_writes https://en.wikipedia.org/wiki/Persistence_(computer_science)... I first heard of that in context of writing to the screen, actually, when you don't want to redraw all the things every frame, or simply can't afford to, and only draw the things that have changed (i.e. are "dirty"). So if you were to keep track of the old position of an object, you might redraw the area of background where that object was, and then just draw the object at the new position, instead of drawing the background for the whole screen, and then the object. Browsers are also kinda heavy on this when it comes to both layout and drawing. E.g. when the content of a div with fixed size changes, you only have to layout and draw the text in the div -- but if the size isn't fixed, you might relayout and redraw everything on the page that follows the div, but might not need to touch anything that comes before it. I'm sure it's incredibly complex, but still much faster than not doing it.
virmundi 8y ago
Sure. I have a Profile. Let's say I load it from the database and make a change. I want to know if I need to save the profile. This is particularly important when using optimistic locking, a.k.a. resource versioning. My profile has a version number, like an ETag. I only want to update if there is a real change, and updating increases that revision number with every persist. Here's a scenario. A woman gets married. Her last name changes. She updates the profile from Smith to Jones. The last name is now dirty. The code that save the object can say, "Are you dirty?" The struct says, "Yup". Saving code says, "Right! In you go." On the other side, the bit gets flipped back to false (it's cleaned). At the end, the revision updates by one and goes back to the client. Another scenario. A user opens the edit profile box, doesn't change anything, but hits save. Without a dirty check, the object, which hasn't fundamentally change, gets saved with a new revision number. Now what is all this about the revision number? I don't want to allow changes to a profile whose revision number is greater than the revision number my client passes. Let's say the Profile has revision 5. The client, which has been disconnected for a bit, says, "Update the profile, at revision 2, with all this new great data." The system needs to reject that update. The client needs to tell the user, "Sorry. That didn't work. Here's all this new data." If the client is especially Canadian, it will also say, "Oh, by the way we've saved your data, would you like us to copy it over the new data". I've never seen Canadian code, and mine is especially Floridian, but it could happen like that. All of this is fairly easy in OO languages, which Go is not. It's actually easy in Go too if you use -ters and Setters (Go doesn't like GetFirstName(), but is okay with FirstName()). If I use functions attached to structs, easy. Just curious how other feel about this.
- vthallam 8y ago
  We use functions on the struct. I know it's not ideal but just works for us.

rpeden 8y ago

Maybe store a hash of the values in the struct and check against that too see if anything has changed? If you're doing lots of dirty checks, that might be too resource intensive, though. Or just use getters and setters and if anyone calls you stupid, ask them to demonstrate a better solution that still solves your problem.