You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry for the so late response. I considered the pros and cons of introducing the REPLACE INTO in this library.
About the benefits, processing insert / update operation at once. Probably it might be a responsibility of stored procedure or application side, but it can be easily archived by the powerful function of MySQL.
On the other hand, the original gorm is compatible with major RDB such as MySQL, PostgreSQL, and SQLite, and I think it is not desirable to have a function depending on a specific database.
Also, REPLACE INTO executes delete and insert if correspond record exists. This is dangerous when cascade foreign key constraint is set, related records will be deleted at the same time.
From these perspectives, I think the responsibility of REPLACE INTO should be retained by the application.
If you have a different idea, could you write it here? I'll rethink about it again.
It'll be good if the INSERT INTO is changed to REPLACE INTO, so that rows will be updated/created accordingly
The text was updated successfully, but these errors were encountered: