Sorry hoor, maar die hele discussie vind ik een schitterend voorbeeld van een stelletje oetl*llen die terug moeten naar de zolderkamer.
Dat de 1e persoon een slecht idee bedenkt en dat niemand het direct ziet, allee. Kan gebeuren.
Maar op het moment dat er iemand gaat melden dat het op een duitse versie niet werkt omdat er geen engels woordje in staat dan moet je toch wel enigszins onraad gaan ruiken. Hoe zit het dan bijv met een russische windows, of een chinese windows, of weet ik veel wat voor lokalised windows / linux er zijn die niet 100% engels uitspugen.
Als je daarbovenop nog iemand krijgt die zegt dat er directory verschillen tussen winxp en w2k zitten dan moet je als serieuze programmeer zo ongeveer iets hebben van : WTF hoe heb ik dat kunnen doen...
Dan maar een environment variable gaan pakken die gewoon aan te passen is op user-nivo en helemaal niet gegarandeerd altijd aanwezig zal zijn (echt blind prutswerk).
En wat is dan de eindconclusie van die dag : C-implementatie is te veel werk en 4 maanden later is het onderdeel van de standaard.
Echt, hoe krijgen die mensen dit voor elkaar

.
Ik vind het best als je het zo doet maar zet dan wel even in giga-grote rode letters een warning dat je product enkel maar geschikt is voor een engelstalige windows-versie die verplicht een environment variable moet waar de windows-directory is. Want anders kunnen er geen GUID's gemaakt worden.
Ach, het positieve eraan is dan wel weer dat ze niet een cmd-prompt openden, daar een screenshot van maakten en die gingen ocr'en om te achterhalen wat er stond, dat was nog net iets erger geweest. Dan had er namelijk in de warning bijgemoeten : U mag ook geen commandprompts standaard minimized openen of offscreen openen en u mag ook niet het klembord afvangen want dan kunnen er wellicht ook geen GUID's gecreëerd worden.
RobIII schreef op donderdag 13 augustus 2015 @ 02:27:
[...]
Even uitgaande van fatsoenlijke implementaties (bugs dus daargelaten): je houdt ook rekening met 't feit dat een bit door kosmische straling van 0 naar 1 kan flippen of andersom? Want, to be honest, die kans is nog steeds veel groter

Je negeert het feit dat ik geen garantie kan geven dat iets gecreëerd is met een fatsoenlijke implementatie.
A : Bugs zijn niet enkel theoretisch
B : Implementatiefouten zijn al helemaal niet enkel theoretisch
C : Een kenmerk van een Guid (dacht ik tenminste totdat iemand me corrigeerde qua v4) is dat die pogen uniek te zijn. Oftewel als ik een guid aangeleverd krijg van derden of van iets totaal anders hoef ik me in theorie helemaal niet druk te maken om of de implementatie fatsoenlijk is geweest (zolang het resultaat maar goed is). Alleen in de praktijk is niet elke implementatie fatsoenlijk.
[...]
"100% for all intents and purposes" wel. Zie vorige alinea.
Mits je je beperkt tot eigen gecreëerde guid's op 1 bekende machine in een algemeen vastgebakend en bekend domein dan wel.
Mijn realtiteit is echter over het algemeen dat ik best een database aangeleverd kan krijgen die entry's van 5 jaar geleden bevat gemaakt op een debian machine die een week ongepatched was.
Of het kan schijnbaar ergens met python gegenereerd zijn (zie boven)
[...]
Daar zijn we het inmiddels allemaal wel over eens (even in 't midden gelaten wat men nou steeds bedoelt met "checken": a) inserten en dup. key exception vangen of b) select + insert of c) <anders>...)
In theorie geen b (want dan moet je opeens de database single-transaction based maken of ervoor zorgen dat je uitvoerende agent maar 1 statement te gelijk kan verwerken)
Maar in principe is het geen definitief a of c, het is afhankelijk van de situatie.
Als je buiten ACID-dbases gaat kijken dan is de kans al weer wat groter dat er helemaal geen dup key exception is (bijv nosqls willen er nog wel eens een handje van hebben met mooie termen als "async inladen" en "eventual consistency" etc)
De vraag is of het de moeite / geld / tijd waard is om af te handelen of de catch gewoon leeg te laten bijvoorbeeld. En dus is het, zoals ik blijf roepen, afhankelijk van de situatie. Mis ik bij een dup. key een like in m'n FeestBoek db op de honderziljard likes (en dus zijn de stakes nihil)? Of gaan er mensen dood aan radioactieve fallout vanwege een dup. key exception die ik niet afhandel / vergeet af te handelen (en dus zijn de takes hoog). Dat is mijn hele punt all along.
Deels waar, alleen is het ook maar net de vraag of je alles kan overzien. Als je FB benoemt, dan denk ik ook dat die niet voorzagen dat logdetails van out of policy items niet bewaren best kostbaar kan worden als het om wraakporno gaat...
Gaat de staatsloterij morgen een miljoen uitdelen aan de persoon die de honderziljardste like doet dan denk ik ook dat de kosten nog wel eens hoog zouden kunnen uitvallen (ik ken niet de exacte voorwaarden van FB en het boeit me ook niet echt voor het voorbeeld), dit soort type acties zijn er al. Enkel de prijzen zijn niet hoog zodat de kosten als het niet aankomt ook niet hoog zijn voor een FB (mochten ze het garanderen)
al blijf ik me verbazen over hoe groot men denkt dat die kans is (buggy implementaties, PEBKAC en andere zaken daargelaten, en dan verwijs ik wel nog even naar m'n eerdere NIH/RTW opmerking: ik zou er nog steeds altijd voor kiezen de (G/U)UID generator van het platform waarop ik ontwikkel te gebruiken totdat 'ie buggy blijkt of de stakes/budget moeten hoog genoeg zijn om een onderzoek ernaar te doen / een code review te warranten / ...whatever => situatie/project afhankelijk dus; net zoals er situaties zijn waar een simpele sequence of distributed (namespaced) generated ID van toepassing is).
Ach ja, omgekeerd blijf ik me dan weer verbazen dat mensen NiH ook toe blijken te passen op guid's.
Terwijl mijn beeld / ervaring juist met guid's is dat die van pas komen juist als ik over meerdere systemen / implementaties etc heen ga werken.
Als het enkel binnen mijn eigen controleerbare domein zou blijven zou ik een guid (zeker nu ik zie hoe v4 werkt, maar daarvoor vond ik het ook al te duur) niet snel gebruiken.
En zeker met de standaard kosten voor een check (in 99% van de gevallen totaal niet relevant) zou ik echt niet wachten met dat een implementatie buggy benoemd is, of de stakes hoog genoeg zijn om een onderzoek te starten.
Gewoon in het grote interne coding guidelines book dat het standaard gechecked en afgevangen moet worden inclusief implementaties etc en ik ben op 1000 projecten waarschijnlijk nog goedkoper uit dan als ik ook maar op 1 project onderzoek moet gaan doen of de implementatie buggy is.
Ik denk dat als ik moet gokken dat bij 60% van de excepties die ik afvang ik er niet vanuit ga dat het ooit op gaat treden als iedereen alles correct implementeert en handelt. Een SQL-server die in hetzelfde gebouw op dezelfde noodstroomvoorziening staat die valt niet zomaar spontaan even weg