[MySQL] Update query in bash script

[Yagermeister]

Mijn vraag

Ik heb een script geschreven waar ik een aantal files doe downloaden, aanpassen en als laatste doe ik een sql update query uitvoeren.

Het probleem wat ik heb is dat de update query niet werkt in het script.

#!/bin/bash
mysql -h localhost -u user -p'wachtwoord' magento2 -e "UPDATE sales_order SET increment_id = $OrderId WHERE customer_email LIKE '%$Email%'"
mysql -h localhost -u user -p'wachtwoord' magento2 -e "UPDATE sales_order_grid SET increment_id = $OrderId WHERE customer_email LIKE '%$Email%'"

Als ik dit met de hand uitvoer werkt het prima op de commandline maar in het script geeft hij de volgende foutmelding:

ERROR 1062 (23000) at line 1: Duplicate entry '4563453450-1' for key 'SALES_ORDER_INCREMENT_ID_STORE_ID'
ERROR 1062 (23000) at line 1: Duplicate entry '4563453450-1' for key 'SALES_ORDER_GRID_INCREMENT_ID_STORE_ID'

Het rare is dat hij die -1 achter de order zet ondanks dat de variable deze niet erin heeft. Ik heb al vanalles geprobeerd met ' en/of " maar niks lijkt te werken.

Weet iemand misschien wat ik moet gebruiken om dit aan te roepen vanuit een script?

[Arjan A]

Wat zie je als je de query eens laat echo-en of naar een logbestand stuurt?

[GlowMouse]

De waarde '4563453450-1' is, zoals de foutmelding al zegt, de waarde die in de index 'SALES_ORDER_INCREMENT_ID_STORE_ID' tweemaal dreigt voor te komen. Dat is dus de combinatie van order id en store id. In de query zul je dus 'gewoon' de waarde 4563453450 hebben staan, maar die waarde is niet toegestaan omdat er al een rij met die waarde bestaat (voor store id 1).

[ Voor 28% gewijzigd door GlowMouse op 07-03-2018 16:17 ]

[Yagermeister]

Arjan A schreef op woensdag 7 maart 2018 @ 16:10:
Wat zie je als je de query eens laat echo-en of naar een logbestand stuurt?

Dit ga ik even proberen als ik een order binnen krijg om te verwerken.

GlowMouse schreef op woensdag 7 maart 2018 @ 16:16:
De waarde '4563453450-1' is, zoals de foutmelding al zegt, de waarde die in de index 'SALES_ORDER_INCREMENT_ID_STORE_ID' tweemaal dreigt voor te komen. Dat is dus de combinatie van order id en store id. In de query zul je dus 'gewoon' de waarde 4563453450 hebben staan, maar die waarde is niet toegestaan omdat er al een rij met die waarde bestaat (voor store id 1).

Dat is net het gekke. Ik maak nergens in de query gebruik van de store_id. Het is zelfs zover dat de hele storeid niet eens in het script voorkomt of zelfs een referentie ergens is.

[GlowMouse]

Yagermeister schreef op woensdag 7 maart 2018 @ 16:23:
[...]

Dat is net het gekke. Ik maak nergens in de query gebruik van de store_id. Het is zelfs zover dat de hele storeid niet eens in het script voorkomt of zelfs een referentie ergens is.

Dat hoeft ook niet om een duplicaat te krijgen. Lees nou eens rustig wat er staat.

[CurlyMo]

Je weet wel zeker dat je bash script niet aangeroepen kan worden met:

code:

~ # ./update.sh 4563453450 '.com'

[Yagermeister]

GlowMouse schreef op woensdag 7 maart 2018 @ 16:32:
[...]

Dat hoeft ook niet om een duplicaat te krijgen. Lees nou eens rustig wat er staat.

Sorry ik heb een stukje gemist. Je geeft aan dat er een dubbele waarde in de tabel zit echter is dat niet zo want als ik daarna de update query met de hand uitvoer werkt die wel gewoon.

CurlyMo schreef op woensdag 7 maart 2018 @ 16:42:
Je weet wel zeker dat je bash script niet aangeroepen kan worden met:

code:

~ # ./update.sh 4563453450 '.com'

Nee want de variable worden in het script zelf pas aangemaakt.

Om een idee te geven van het script:

Het script start door de Bol orders XML te downloaden. Deze wordt daarna middels een R script omgezet naar CSV. Deze CSV wordt dan per regel uitgelezen en met die info wordt een file gemaakt voor onze leverancier en een andere file wordt aangemaakt om dan in Magento 2 te importeren.

Na het importeren doe ik de update query om de correcte order nummers in het systeem te hebben staan. Dit deed ik eerst door middel van een php script wat ik opriep maar nu heb ik precies die query daaruit gehaald en in het script gezet. Dit was meer omdat het me niet lukte om de php aanroep string correct te krijgen.

[CurlyMo]

Wat je ook zou kunnen doen is gewoon de XML direct in een database import tabel dumpen en dan al je data transformaties binnen MySQL doen. Dan heb je geen R nodig. MySQL ondersteund gewoon xpath.

[GlowMouse]

Yagermeister schreef op woensdag 7 maart 2018 @ 16:57:
[...]

Je geeft aan dat er een dubbele waarde in de tabel zit echter is dat niet zo

MySQL geeft die melding toch echt niet zomaar. Door je update-query dreigt een dubbele waarde te ontstaan. Je kunt zeggen dat het niet zo is, maar je kunt beter uitzoeken waarom het toch zo is. Ik steek mijn hand ervoor in het vuur dat MySQL op dit punt geen bug bevat.

[base_]

Wow jij gaat je magento 2 salles orders manipuleren vanuit een bash script? Ik hoop dat je weet dat je hiermee allee magento hooks, indexing en andere magento functionaliteit omzeilt? Meestal wordt er een magento script gemaakt voor het manipuleren van magento data. Zowiezo gaat het updaten van increment_id op basis van email adres gegarandeerd problemen opleveren: zodra een klant meerdere orders op hetzelfde email adres gemaakt heeft.....

[.Johnny]

Het is moeilijk te beantwoorden zonder een duidelijk beeld van het datamodel en de keys en constraints.

dit bijvoorbeeld:
"UPDATE sales_order SET increment_id = $OrderId WHERE customer_email LIKE '%$Email%'"

Het lijkt er dus op dat increment_id een gecombineerde unique key is met store-id. Doordat je een update doet op basis van een email adres kan het toch prima zijn dat je probeert meerdere rijen tegelijk een zelfde increment_id te geven (die statisch is, want $OrderId). Stel je hebt:

sales_order:
increment_id, customer_email, store_id
x, y, z
2, y, z

en nu doe je:
"UPDATE sales_order SET increment_id = P WHERE customer_email LIKE '%y%'"

Dan hang je al, want hij wil dit maken:
increment_id, customer_email, store_id
P, y, z
P, y, z
maar dat kan niet volgens de constraint.

Om goed te debuggen raad ik je aan het probleem te reproduceren in een zo minimale setting als mogelijk is. Ik vermoed dat je tijdens die reis je probleem zelf al oplost, maar zonder die stappen is het hier gewoon gissen waar het mis gaat.

[Hero of Time]

En je wilt al helemaal geen wildcards gebruiken als je op email adres gaat zoeken. Het bestaat, of bestaat niet. Wat als je nou de email adressen "[e-mail]" en "[e-mail]", en j.jansen besteld iets. Dan krijgt pj.jansen spontaan een bestelling toegewezen. Echt, geweldige manier om met je klantgegevens om te gaan.

* Hero of Time geeft @Yagermeister alvast een paracetamol voor de pijn die gaat komen in de voet.

[The Eagle]

Ik vermoed dat je probleem veroorzaakt wordt door een implicit commit bij het afsluiten van je sessie.
Sessie openen, Eerste update statement, sessie sluiten en auto commit
Vervolgens idem voor tweede statement

Makkelijk te testen of dat het issue is; open msql sessie, vuur statement 1 handmatig af, commit, statement 2, commit. Zou me niks verbazen als ie dan de zelfde fout geeft

Heeft te maken met transaction logging en de status van de data in je DB cq sessie buffer.

[Yagermeister]

CurlyMo schreef op woensdag 7 maart 2018 @ 17:02:
Wat je ook zou kunnen doen is gewoon de XML direct in een database import tabel dumpen en dan al je data transformaties binnen MySQL doen. Dan heb je geen R nodig. MySQL ondersteund gewoon xpath.

Dat wordt eigenlijk fase 2 van het project aangezien ik daar nog geen ervaring mee heb op dit moment.ect aangezien ik daar nog geen ervaring mee heb op dit moment.

GlowMouse schreef op woensdag 7 maart 2018 @ 17:08:
[...]

MySQL geeft die melding toch echt niet zomaar. Door je update-query dreigt een dubbele waarde te ontstaan. Je kunt zeggen dat het niet zo is, maar je kunt beter uitzoeken waarom het toch zo is. Ik steek mijn hand ervoor in het vuur dat MySQL op dit punt geen bug bevat.

Ik zeg ook niet dat het een bug is. Vanmorgen heb ik echter de oplossing gevonden en die zal ik even hieronder neer planten. Het was een typefout van mijn kant.

base_ schreef op woensdag 7 maart 2018 @ 17:08:
Wow jij gaat je magento 2 salles orders manipuleren vanuit een bash script? Ik hoop dat je weet dat je hiermee allee magento hooks, indexing en andere magento functionaliteit omzeilt? Meestal wordt er een magento script gemaakt voor het manipuleren van magento data. Zowiezo gaat het updaten van increment_id op basis van email adres gegarandeerd problemen opleveren: zodra een klant meerdere orders op hetzelfde email adres gemaakt heeft.....

Klopt. Deze magento 2 installatie wordt echter alleen intern gebruikt en hier staan alleen wat dingen in wat niet zo bijster uitmaken. Het kan inderdaad zo zijn dat het email adres anders is echter is het zo dat het Bol mail adres elke paar maanden wijzigt waardoor je vrijwel nooit hetzelfde adres kan krijgen. Dit met de email is ook maar een tijdelijk iets. Ik pak later hiervoor het orderid welke ik ook ter beschikking heb.

.Johnny schreef op woensdag 7 maart 2018 @ 17:09:
Het is moeilijk te beantwoorden zonder een duidelijk beeld van het datamodel en de keys en constraints.

dit bijvoorbeeld:
"UPDATE sales_order SET increment_id = $OrderId WHERE customer_email LIKE '%$Email%'"

Het lijkt er dus op dat increment_id een gecombineerde unique key is met store-id. Doordat je een update doet op basis van een email adres kan het toch prima zijn dat je probeert meerdere rijen tegelijk een zelfde increment_id te geven (die statisch is, want $OrderId). Stel je hebt:

sales_order:
increment_id, customer_email, store_id
x, y, z
2, y, z

en nu doe je:
"UPDATE sales_order SET increment_id = P WHERE customer_email LIKE '%y%'"

Dan hang je al, want hij wil dit maken:
increment_id, customer_email, store_id
P, y, z
P, y, z
maar dat kan niet volgens de constraint.

Om goed te debuggen raad ik je aan het probleem te reproduceren in een zo minimale setting als mogelijk is. Ik vermoed dat je tijdens die reis je probleem zelf al oplost, maar zonder die stappen is het hier gewoon gissen waar het mis gaat.

De fout heb ik gelukkig gevonden en dat was puur een variable fout. Ik heb hierboven $Email geschreven maar dat moest dus $EMAIL zijn. Beetje domme fout van mij.

Hero of Time schreef op woensdag 7 maart 2018 @ 17:47:
En je wilt al helemaal geen wildcards gebruiken als je op email adres gaat zoeken. Het bestaat, of bestaat niet. Wat als je nou de email adressen "[e-mail]" en "[e-mail]", en j.jansen besteld iets. Dan krijgt pj.jansen spontaan een bestelling toegewezen. Echt, geweldige manier om met je klantgegevens om te gaan.

* Hero of Time geeft @Yagermeister alvast een paracetamol voor de pijn die gaat komen in de voet.

Heb je helemaal gelijk bij. Zoals hierboven ook aangegeven is dat iets wat nog gaat wijzigen en het email is vrijwel nooit 2x hetzelfde doordat Bol ze versleutelt aanleverd. Daarbij is de hele constructie alleen voor intern gebruik en wordt er ook niet mee gemailed.

The Eagle schreef op woensdag 7 maart 2018 @ 17:58:
Ik vermoed dat je probleem veroorzaakt wordt door een implicit commit bij het afsluiten van je sessie.
Sessie openen, Eerste update statement, sessie sluiten en auto commit
Vervolgens idem voor tweede statement

Makkelijk te testen of dat het issue is; open msql sessie, vuur statement 1 handmatig af, commit, statement 2, commit. Zou me niks verbazen als ie dan de zelfde fout geeft

Heeft te maken met transaction logging en de status van de data in je DB cq sessie buffer.

Bedankt voor de tip. De fout is zoals hierboven beschreven een schrijffout in de variable. Ik had geen caps gebruikt terwijl ik de variable wel in volledige caps had geschreven. Normaal copy en paste ik die altijd alleen deze keer had ik dat niet gedaan.

[Hero of Time]

Yagermeister schreef op donderdag 8 maart 2018 @ 11:27:
[...]

Heb je helemaal gelijk bij. Zoals hierboven ook aangegeven is dat iets wat nog gaat wijzigen en het email is vrijwel nooit 2x hetzelfde doordat Bol ze versleutelt aanleverd. Daarbij is de hele constructie alleen voor intern gebruik en wordt er ook niet mee gemailed.

Het gaat helemaal niet om het wel of niet gebruiken van het email adres om er meer mee te doen. Je gaat wildcards gebruiken bij een update query. Dat is gegarandeerd smeken om gezeik. En je gaat er ook gegarandeerd eens mee in je voet schieten. Je wilt geen rijen bijwerken als een veld een waarde heeft dat ook maar lijkt op wat je wilt. Het moet precies zijn zoals je wilt.

Een beetje databasebeheerder of SQL guru zou je om je oren slaan voor het schrijven van zo'n foute query.

[Yagermeister]

Hero of Time schreef op donderdag 8 maart 2018 @ 13:57:
[...]

Het gaat helemaal niet om het wel of niet gebruiken van het email adres om er meer mee te doen. Je gaat wildcards gebruiken bij een update query. Dat is gegarandeerd smeken om gezeik. En je gaat er ook gegarandeerd eens mee in je voet schieten. Je wilt geen rijen bijwerken als een veld een waarde heeft dat ook maar lijkt op wat je wilt. Het moet precies zijn zoals je wilt.

Een beetje databasebeheerder of SQL guru zou je om je oren slaan voor het schrijven van zo'n foute query.

Ik zal me diep schamen en zo snel mogelijk gebruik gaan maken van het order id

[.Johnny]

De logica lijkt inderdaad te zijn "het werkt nu dus heb ik het goed gedaan". Gevaarlijke aanname.

Goed, we zien vanzelf wel een nieuw topic verschijnen met wat er nu weer niet werkt, of hoe de hele administratie recovered kan worden. Lieve help!

[Yagermeister]

.Johnny schreef op vrijdag 9 maart 2018 @ 08:49:
De logica lijkt inderdaad te zijn "het werkt nu dus heb ik het goed gedaan". Gevaarlijke aanname.

Goed, we zien vanzelf wel een nieuw topic verschijnen met wat er nu weer niet werkt, of hoe de hele administratie recovered kan worden. Lieve help!

Zo erg is het ook weer niet aangezien de database alleen gebruikt wordt om de Bol factuur te kunnen aanmaken. Dit kunnen we ook met de hand en hebben we altijd al gedaan. Daarbij is het script al aangepast zodat het gebruikt maakt van het order id.

Ik snap best dat iedereen de best mogelijke oplossingen wilt geven en dat waardeer ik ook ten zeerste echter is dit niet altijd mogelijk om dit uit te rollen in het tijdsbestek dat wij hebben.