postgres tervezési hiba

Sziasztok! 

Ez a hiba csak a postgres alatt merül fel egyáltalán. 

Egy hosszú hiszti helyett. Itt egy példa kód:

CREATE TABLE test_new (
    id serial primary key ,
    payload text
);

insert into test_new (payload ) values ('sf');
insert into test_new (payload ) values ('sf');
insert into test_new (id,payload ) values (3,'sf');
insert into test_new (id,payload ) values (4,'sf');
--SELECT setval('test_new_id_seq', max(id)) FROM test_new e ;--igen ez lenne a megoldás
insert into test_new (payload ) values ('sf');

Szükségem lenne arra, hogy betöltsek adatokat. Több embernek volt már ezzel baja, de egy jó rtfm-et nem találtam. Valami egyszerű triggert írt már rá valaki?

Hozzászólások

Szerkesztve: 2020. 06. 16., k - 15:24

Én nem látom hol a hiba. És a leírásodból sem derül ki. Mi a bajod pontosan?

Azzal küzd, hogy csinál egy auto increment-es oszlopot, aminél a számot az adatbázis kezelő vezérelne, de utána mégis csak úgy gondolja, hogy

majd ő megmondja, hogy mi legyen a következő azonosító. Hát, ez így nem fog menni, lévén a Postgresql egy sequence-et fog létrehozni.

Tiszta, hogy mi a hiba oka. De nekem kellene valami olyan típus amit a serial helyett tudnék használni. Ami egyenértékű a mysql féle AUTO_INCREMENT-el.

Vagy bármi. A megoldás sem lehet bonyolult egy trigger kell ami mindig növeli az értéket. De ha már valaki megírta akkor ne kelljen nekem újra.

Nem tervezési hiba, egyszerűen ne keverd az automatikus és a manuális sorszámozást, ahol külön sequence táblából kapod a sorszámokat.

Ez a te barátod:

ALTER SEQUENCE test_new_id_seq RESTART WITH 5;

Szerkesztve: 2020. 06. 16., k - 18:12

insert -nél az id-hez seq.nextval -t írjál amikor nem tudod és a számot amikor tudod.

persze innentől neked kell arról gondoskodnod hogy a sequence-d átugorja amit manuálisan felhasználsz, különben nem lesz unique az id.

Gábriel Ákos

Erre milyen felhasznalasnal van szukseg? Nincs olyan tartomany, amit nem akarsz neki kezzel adni, es amibol oszthat automatikusan a sequence-ed?

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ez nem bug, feature. Igen, más feature mint a MySQL-ben. Erre - mármint hogy a MySQL != PostgeSQL, és ennek megfelelően kell tervezni a rendszert - az Uber is rájött, csak ők valószínűleg millió USD nagyságrendű összeget buktak rajta. :)

A kontextus ismerete nélkül nem tudunk érdemben segíteni. Ha tényleg csak DDL-lel tudsz belenyúlni, tehát az appot nem lehet módosítani, akkor egy INSERT triggerrel valószínűleg meg lehet oldani, ahogy azt már írták fentebb. De ehelyett a helyes megoldás egy adatbázis absztrakciós réteg bevezetése lenne az alkalmazás oldalán, ami a hasonló, SQL featureset / dialektus különbségekből adódó problémákat el tudja fedni az alkalmazás elől.

Erre - mármint hogy a MySQL != PostgeSQL, és ennek megfelelően kell tervezni a rendszert - az Uber is rájött, csak ők valószínűleg millió USD nagyságrendű összeget buktak rajta

Elolvasnám a sztorit, ha megvan neked a link. Ha nincs meg, akkor megkérdezem majd Google barátomat.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ezt így nem írták le sehol, csak 1-2 éve végighaknizták a sajtót / podcast / blogosphere-t, hogy ők most Postgresről visszaváltanak MySql-re.

És azokból az interjúkból derült ki az, hogy "valami" miatt átváltottak MySQL-ről Postgresre. Illetve konkrétabban úgy tűnt, hogy problémáik voltak a MySQL séma update-ekkel, konkrétan ha hibás volt egy update script, akkor az inkonzisztens állapotban hagyta a DB-t, emiatt aztán lehetett backupból visszaállni. Postgresnél ugye ilyen nincs, hiszen simán lehet DDL tranzakciót is rollbackelni.

Aztán rájöttek, hogy a Postgres WAL replikációjának teljesen más a teljesítménykarakterisztikája mint a MySQL logikai replikációjának (akkor még nem volt logikai replikáció Postgresben), és az ő séma tervezési módszerük (legyen mindenen index, mert hátha kell :) ) nem igazán kompatibilis vele. Úgyhogy elkeztek egy schemaless kiterjesztést csinálni MySQL felett... 

Persze lehet, hogy nem is így volt, és ez az egész csak a képzeletem szüleménye.

Nekem nem dob hibát, valamit rosszul csinálok?

postgres=# select version();
                                                     version
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
(1 row)
 

A 4 után simán beszúrja az 5-öt. Ha utána manuálisan szúrok be 15-öt, utána beszúrja automatikusan a 16-ot. Utána manuálisan megy a 6 is. Postgre 11.8-al is megy.