search

ardanlabs / service

Starter-kit for writing services in Go using Kubernetes.
https://www.ardanlabs.com
Apache License 2.0
3.59k stars 649 forks source link

Handling API requests to "clear" values #436

Closed rmsj closed 3 days ago

rmsj commented 5 days ago

In the business logic of the starter kit, the update method checks for a series of optional values. This works fine when we are updating the values but, what when we actually want to clear the value. Set a field in the database to null. How can we differentiate between these requests?

ardan-bkennedy commented 4 days ago

This is a great question and it has never come up with any systems I've built. I'm going to have to think about this and get @paborilov involved. Curious if you have experiements with any ideas?

ardan-bkennedy commented 3 days ago

Since what we have in service is a PATCH, the current semantics make this hard. You could change things to an UPDATE, where the caller must send the full state of the data to be changed. I don't like this semantic because it puts too much on the client. That being said, I'm not sure how to do this otherwise.

ardan-bkennedy commented 3 days ago

Not every field is NULLABLE, so you could have a special value that indicates NULL for those fields. For a string it could be "NULL", for an int it could be negative max int. Just throwing stones.

rmsj commented 3 days ago

Hey @ardan-bkennedy thanks for looking into this. What I have is a workaround. - a mix of what you mentioned above.

For an ID (uuid) that can be null for example, I implemented a NullableID type, that has a different implementation for the sql.Valuer to set the field's value to null if the value equals uuid.Nil (all zeroes) - hence implementing the idea of special value.

The other values I will probably do something similar... at the moment, sending an empty string for example will null a nullable field...

ardan-bkennedy commented 3 days ago

Creating a type is always the best way to go IMHO. I do like to keep with JSON based types in the app layer models. The time.Time is acceptable because of the support it provides for JSON Time. I'm glad you found a work around.

If we are done can you please close the issue.

rmsj commented 3 days ago

Thank you again for your support and attention. I'm happy I selected the start kit for our production environment project.