Changes between Initial Version and Version 2 of Ticket #189


Ignore:
Timestamp:
Feb 13, 2015, 1:11:25 PM (11 years ago)
Author:
Torsten Riemer
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #189

    • Property Milestone modified-shop-2.00 → modified-shop-2.10
    • Property Version 1.06 → 2.10

  • Ticket #189 – Description

    initial v2  
    11Aufgefallen beim Erstellen eines update-Pakets: Um die Tabelle configuration gefahrlos und wiederholbar mit inserts zu aktualisieren, muss erst gecheckt werden, ob es die Einträge schon gibt. Das geht zwar mit SQL, ist aber mühsam:
    22
     3{{{
    34INSERT INTO configuration ( configuration_key, configuration_value, configuration_group_id, sort_order, date_added)
    45SELECT 'MODULE_PAYMENT_BANKTRANSFER_CI', '', '6', '0', now() FROM configuration
    56WHERE NOT EXISTS (SELECT 1 FROM configuration WHERE configuration_key = 'MODULE_PAYMENT_BANKTRANSFER_CI')
    67LIMIT 1;
     8}}}
    79
    810Tabelle configuration sollte sowieso den configuration_key unique haben. Denn zwei Sätze mit dem gleichen configuration_key sind falsch.
    … …  
    1012Dann könnte man das insert so schreiben:
    1113
     14{{{
    1215INSERT INTO configuration ( configuration_key, configuration_value, configuration_group_id, sort_order, date_added) VALUES ('MODULE_PAYMENT_BANKTRANSFER_CI', '', '6', '0', now())
    1316ON DUPLICATE KEY UPDATE configuration_key = configuration_key
     17}}}
    1418
    1519oder so:
    1620
     21{{{
    1722INSERT IGNORE INTO configuration ( configuration_key, configuration_value, configuration_group_id, sort_order, date_added) VALUES ('MODULE_PAYMENT_BANKTRANSFER_CI', '', '6', '0', now())
     23}}}
    1824
    1925INSERT IGNORE hat den Nachteil, dass *alle* Fehler ignoriert werden, ON DUPLICATE hat dieses pseudo-update am Ende, ist aber sicherer.