Conversation
|
Why bother with this? I don't see the advantage vs. the extra code required to support it. |
|
Why send extra data over to the database if it isn't necessary? The DB is usally the bottleneck anyway, not webfronts. PostgreSQL has optimizations that makes an UPDATE in-place unless the UPDATE-query touches a field with an index on it, then it needs to create a whole new row in the table, resulting in the need for VACUUM/REINDEX etc. Another usecase would be if you have a big field in your model, say a field storing some binary encoded data. To send it over to the database when you're just increasing a counter seems unnecessary. What if you have some triggers on the DB-side on specific field-updates, they would trigger all the time although not really changed. The DB-logs will also be cleaner, easier to see exactly what rows being updated. |
|
Another reason: Less risk of overwriting data if two processes updates the row right after eachother, the second process could have "stale" unchanged fields that shouldn't be stored in the DB. |
|
Closing pull request |
|
Why? I'm still considering this feature. It seems like a good idea. |
|
I closed it due to me being sloppy and committing some stuff to master instead of a specific feature-branch polluting this request :) |
Keep track of changed fields and only UPDATE those when doing save()
ID is also updateable with this patch, maybe it's not desireable?