Hledání „Nette-like“ ORM pro PHP

Doctrine 2 bych tak rychle nezavrhoval, může se zdát velká, ale je překvapivě rychlá. A hlavně, řeší za tebe persistenci entit a ty se můžeš pak plně soustředit na DDD. Byl jsem k ní také skeptický, načti si reference, ať vidíš co všechno s ní nebudeš muset vynalézat :)

Doctrine 2 má tolik pokročilých funkcí, že kdybys ji chtěl použit až na zastřelení něčeho přiměřeně velkého tak by sis nevystřelil. :-) Je lepší začít od těch vrabců.

Momochodem Doctrine 1 a 2 mají společné v podstatě jen jméno. Dost věcí je v Doctrine překvapivě jednoduchá, naopak časem přijdeš na dost jiných věcí, které jsou překvapivě složité. Rozhodně ale doporučuji ji zkusit.

A prečo nepoužiješ NotORM? Tá má funkciu $db->rowClass = ‚ClassName‘, to je ekvivalentné k setRowClass. A v NotORM sú aj iné vylepšenia, ktoré nie sú v Nette\Database.

Jakub pridáva nové vlastnosti a opravy len do NotORM a pre Davida, zdá sa, nie je prioritou backportovať nové vlastnosti z NotORM do Nette\Database.

Odporúčam začni srigiho kuchárkou.

@dcepelik: Pokud vydržíš ještě tak týden, připravuji screencast o budování modelu rozděleného do vrstev s entitami, repositáři a mappery, kde bude ukázkový mapper napsaný v dibi. Jsem časově ve skluzu, protože mám kašel a namlouvat v mém současném zdravotním stavu screencast by vyvolávalo u diváků napětí, zda-li se aktér dožije konce ;). Ale kódy už mám hotové, a tak kdybys chtěl nahlídnout…

Btw. u té mé koncepce není nejmenším problémem dopsat další mapper založený nad Nette\Database a jelikož se dibi už pravděpodobně nebude v budoucnu nijak rozvíjet, asi na ten mapper nad Nette\Database sám přejdu. Jedinou nevýhodou by bylo to, že by se tak zahodily ty jeho „related fíčurky“ a to jeho spojování tabulek, protože vazby mezi tabulkami osobně řeším až v repository vrstvě (u 1:N provazuji entity dokonce až v ještě vyšších vrstvách, inspirován NotORMem pomocí IN operátoru) a Nette\Database by samozřejmě figurovalo pouze v mapperu. V podstatě by tam pak Nette\Database sloužilo jen jako obálka nad PDO, ale zato kvalitní. Láká mě na tom to, že by to výkonem mohlo být i lepší než mapper využívající dibi a hlavně by to využívalo nativní součást Nette.

Z Tvých komentářů mám dojem, že jsem prošel úplně stejným rozčarováním, jako Ty. Doctrine 2 mě opravdu odradilo svou robustností a musím říct, že jsem mu dával šanci několikrát. Prostě mi k Nette nějak vůbec neladí… K Zendu asi super, ale Nette osobně pořád považuji za light-weight a nějak mi ty knihovny nejdou k sobě (totálně subjektivní pocit, tímto zcestným názorem se rozhodně nikdo neřiďte!).

NotORM je fajn a taky jsem ho chvíli používal, ale já jsem nepřekousl to, že se snažím psát vcelku hezký a čistý kód, a najednou se v něm dějí podobné čachry se všemi těmi __get(), __set(), __call(), ArrayAccessy a podobně. V mých očích je NotORM geniální, ale nějak neladí k mému kódu… Já chci v presenterech pracovat s konzistentními Entitami a ne s nějakými NotORM_Row a podobně. No a tak jsem si napsal ty jednoduché vrstvy, o kterých tvrdím, že jsou totálně nedokonalé, ale vyhovují mi určitě nejlépe.

Editoval Tharos (15. 6. 2011 0:45)

@dcepelik: Pošli mi e-mail (přes profil), klidně příklad těch kódů někdy během dneška pošlu. Ber ale určitě na vědomí, že je to jen úplné jádro bez nějakých ozdob a není to v tom kódu, co bych poslal, nijak hezky integrované v podobně služeb. To už mám též realizované (i spolu s několika dalšími myšlenkami), ale nemám „volnou“ ukázku, kterou bych mohl zaslat (rozuměj vše je součástí nějakých projektů, kde bohužel nesmím šířit kódy).

No, jsem docela zvědav na oponenturu, protože ono je to v principu podle mě úplně banální kus kódu a má to celé opravdu pár řádků (cca 400 důležitých). Ale mně se s tím prostě pracuje dobře… A omezenou funkcionalitu mi dostatečně kompenzuje to, že to nepotřebuje 333 includovaných souborů. :)

Jakub, že by bolo výborné, keby si si našiel čas urobiť ten videotutoriál alebo článok (to je jedno), ktorý si sľuboval pred nejakým časom, ako robiť modely a doménovú logiku pri použití NotORM, najlepšie v nette na nejakom jednoduchom príklade. Zdá sa, že viacerí nad tým rozmýšľame a hľadáme best-practice riešenie.

@Tharos: Mohl bys mi taky poslat ukázky kódu? Dělám v práci na jednom větším projektu a taky jsem byl dohnán k psaní si vlastního podobného „ORM“ – z podobných důvodů jako ty. Mám v hlavě i nějaké nápady, jak následně takovou modelovou vrstvu přátelsky propojit s Nette (v konečném důsledku by programátor nemusel nikde pracovat s IDčky, ale to je na delší povídání=)).

Ot@s napsal(a):

Má někdo ze zúčastněných nějakou novinku/novou zkušenost (ohledně tohoto vlákna)?

Vyměnili jsme si s Tharosem několik e-mailů k tématu. I díky němu teď pracuji na velmi jednoduché vrstvě, která je schopna rozumným způsobem řešit persistenci entit. Jednalo by se o nadstavbu nad knihovnami jako NotORM, Nette\Database či dibi.

Jakmile bude věc publikovatelná, uveřejním zde.

Editoval dcepelik (23. 6. 2011 15:16)

Když už jsem se do tohoto vlákna před nějakým časem zapojil, doplním své myšlenkové pochody od mého posledního příspěvku. :)

Od dalšího vývoje té své vlastní vrstvy jsem opustil, protože jsem si na vlastní kůži vyzkoušel jednu věc. Napsat hezký základ vrstevnatého modelu je práce na dva večery (viz třeba HosipLanův článek v kuchařce na toto téma), nicméně komplexnost problému exponenciálně roste, jakmile se začnou řešit vztahy mezi entitami a podobně. Prostě jsem prozřel, že podchytit vše, co už je vyřešeno například v Doctrine 2 či NotORMu, by pro mě osobně byla práce na XYZ hodin a stejně bych to nenapsal lépe, než už to ve zmíněných knihovnách je. Takže tudy cesta nevedla.

Na tomto dojel i můj záměr natočit o vývoji screencast – postupem času mi totiž došlo, že bych prezentoval vývoj něčeho, co v podstatě ale nemá vyvíjet smysl… a to se mi nechtělo.

Mám drobné zkušenosti s Doctrine 2. Doctrine 2 mě v podstatě od začátku nijak extra nepřitahovala (asi ze stejného důvodu, jako například Zend), ale dal jsem jí párkrát šanci, abych si vždy zase znovu uvědomil, že to prostě není nic pro mě. Co mi na ní namátkou opravdu vadilo:

• Programování v anotacích. Anotace jsou super, ale u tříd, kde je více myšlenek realizováno v komentářích než v kódu samotném, jsem trochu na vážkách. Děsně mě štve, že v anotacích mi nenapovídá IDE, nezvýrazňuje mi syntaxi, zkrátka je to totální magnet na chyby a překlepy. Já ale chápu, že to v PHP prostě lépe vyřešit momentálně nelze, ale tak pokud chci vyvíjet tímto způsobem, použiji jiný jazyk (třeba jazyk, který má podporu pro anotace na úrovni jazyka).
• Řada věcí mně přišla děsně neohrabaných a zdržujících při vývoji. Třeba takové DQL, které se skutečně u složitějších struktur musí používat skoro všude – chápu, že oproti SQL je to velký krok kupředu, ale oproti NotORM-like API je to totální brzda.

Čím dál tím více ve svých projektech tedy používám NotORM (který tedy tak nějak „zbyl“) a musím říct, že po nějakém čase jej mám rád čím dál více. Trochu času mi zabralo zvyknout si na ten lehce odlišný styl přemýšlení a také na to svérázné API, ale vše má (jak u Jakuba bývá zvykem) velmi jasně danou logiku, která se mi po nějakém čase skutečně zaryla pod kůži.

Mám pocit, že NotORMu se často vytýká to, že nijak neřeší doménovou logiku a nezabrání tomu, aby se model nedostal do nekonzistentního stavu (na což má Doctrine 2 robustní ochrany). Pokud nepotřebujete měnit databázový systém on-fly a můžete využít možností jednoho vybraného, u většiny systémů tento argument padá (minimálně u novějších verzí MySQL). Nejednou jsem si vyzkoušel, že za pomocí triggerů a vlastních chybových zpráv lze vytvořit takovou databázi, ve které se vám ani omylem nepodaří udělat změnu, která by způsobila narušení doménové logiky (a nesetkal jsem se v praxi s ničím, co by se nedalo v uložených procedurách zvalidovat). A pak je to hračka, protože invalidní akce s NotORMem prostě skončí výjimkou. Ve spojení s důsledným používáním cizích klíčů a striktním módem MySQL mi to skutečně přijde robustnější, než celá Doctrine 2. Co vůbec udělá Doctrine 2, když jí někdo do databáze nějakým jiným kanálem vloží nevalidní data? To se může stát velice snadno (například při nějakém importu dat). Nevšiml jsem si, že by Doctrine 2 generovala ochranu i do databázové vrstvy (kromě cizích klíčů).

Prostě mám pocit, že když jako programátor budu chtít, konzistenci modelu založeného na Doctrine 2 prostě naruším, zatímco konzistenci modelu, který má business pravidla na úrovni databáze nikoliv (samozřejmě databázový uživatel nesmí mít práva volat DROP TRIGGER a podobně…).

Vývoj s NotORMem je to nejrychlejší, co jsem kdy zažil a díky malému množství kódu je málo náchylný k chybám a minimálně u mých aplikací tak klesla i chybovost (a opravdu nejsem placen za to, že bych mu dělal reklamu, jsou to jen mé zkušenosti). Takže pro mě je tím Nette-like ORM momentálně NotORM. :)

Gratuluji všem, co se dočetli až sem :).

Tharos napsal(a):

Toš já ti k tomu přihodím pár poznámek :)

• Programování v anotacích. Anotace jsou super, ale u tříd, kde je více myšlenek realizováno v komentářích než v kódu samotném, jsem trochu na vážkách. Děsně mě štve, že v anotacích mi nenapovídá IDE, nezvýrazňuje mi syntaxi, zkrátka je to totální magnet na chyby a překlepy. Já ale chápu, že to v PHP prostě lépe vyřešit momentálně nelze, ale tak pokud chci vyvíjet tímto způsobem, použiji jiný jazyk (třeba jazyk, který má podporu pro anotace na úrovni jazyka).

Komentáře – uvažuju o annotacích jako o metadatech. Když je reader čte, kontroluje ti syntaxi, takže ten jazyk má pevně dané hranice a mně osobně to velice vyhovuje. Pokud s tím máš ovšem základní filosofický problém, vždycky tu máš ještě možnost PHP mappování a externí XML/YAML.

Napovídání – v Netbeans si můžeš napsat code-templates. Není to sice plnohodnotné napovídání, ale na jednoduché šablonky annotací to stačí. Používám to i u PHPUnit, kde se expectedException, dataProvider a další opravdu hodí :)

Netbeans umí annotace i ztučnit. Doctrine konzole umí annotace validovat a schéma si můžeš verzovat Migracemi a zběžně kontrolovat v databázi.

• Řada věcí mně přišla děsně neohrabaných a zdržujících při vývoji. Třeba takové DQL, které se skutečně u složitějších struktur musí používat skoro všude – chápu, že oproti SQL je to velký krok kupředu, ale oproti NotORM-like API je to totální brzda.

DQL je místy otravné. Ale odkojený na dibi, jsem si na to rychle zvykl :) Dobré je, že člověk si může ty custom DQLka psát do repozitářů.

Mám pocit, že NotORMu se často vytýká to, že nijak neřeší doménovou logiku a nezabrání tomu, … Co vůbec udělá Doctrine … Nevšiml jsem si, že by Doctrine …

To ani není účelem. Doctrine totiž svou podstatou degraduje databázi na pouhé relační úložiště. Dalo by se spekulovat, jestli je to správně, ale tu doménovou logiku prostě není technicky možné přenášet i do databáze, když může být kdekoliv v kódu.

Prostě mám pocit, že když jako programátor budu chtít, konzistenci modelu založeného na Doctrine 2 prostě naruším…

To není pocit, ale fakt. Otázkou je, jak moc velký je to problém.

Takže pro mě je tím Nette-like ORM momentálně NotORM. :)

Ať slouží ;)

@na1k: Já myslím, že přechod může být velmi rychlý, protože na oficiálním webu je v podstatě vše pokrývající dokumentace. K ní můžu dodat jen to, že ač se to nezdá, je v ní opravdu vše (i složitější konstrukce, které jsou zde na fóru všemožně roztroušené, zní lze vydedukovat), akorát „hustota informací“ je tam místy krapet větší, a tak já osobně jsem některé věci plně vstřebal až po pár experimentech.

Co se u mě osobně o něco déle formovalo byla právě ta integrace do Nette. Koukal jsem, že existuje třeba jakási obálka od Srigiho, a já sám jsem při prvních experimentech měl tendenci NotORM nějak „obalovat“, než jsem pochopil, že to je vlastně úplně zbytečné. Je to jako kdybys u Doctrine 2 ještě nějak obaloval EntityManager. Jen je dobré zažít si nějakou štábní kulturu, aby se do šablon dostávaly už jen instance NotORM_Row či NotORM_Result (jako je tomu například u examples Nette\Database) a pak už to jde samo. Zrovna tak například handlerům formulářů, které upravují nějaký záznam předávám pouze potřebné NotORM_Row (vysvětlím ty handlery – já dost striktně odděluji obsluhu formulářů od jejich definic a píši na vše třídy, nemám rád, když se tímto za..dělávají presentery).

HosipLan napsal(a):
Komentáře – uvažuju o annotacích jako o metadatech. Když je reader čte, kontroluje ti syntaxi, takže ten jazyk má pevně dané hranice a mně osobně to velice vyhovuje. Pokud s tím máš ovšem základní filosofický problém, vždycky tu máš ještě možnost PHP mappování a externí XML/YAML.
Napovídání – v Netbeans si můžeš napsat code-templates. Není to sice plnohodnotné napovídání, ale na jednoduché šablonky annotací to stačí. Používám to i u PHPUnit, kde se expectedException, dataProvider a další opravdu hodí :)

Netbeans umí annotace i ztučnit. Doctrine konzole umí annotace validovat a schéma si můžeš verzovat Migracemi a zběžně kontrolovat v databázi.

Samozřejmě, všechno to lze vyladit. Filosofický problém s anotacemi už jsem překousl :), ale ten praktický mi nějak zůstal. Anotace považuji za vynikající pro označení persistentního parametru, provideru u PHPUnitu, zkrátka všude, kde se pracuje vesměs s jedním slovem, ve kterém snad překlep neudělám, a s jednoduchou logikou, kterou nezkazím. To u Doctrine 2 s anotacemi přes několik řádků a s návaznostmi anotací napříč entitami (vlastníci versus inverzní strany) není splněno. Na můj vkus se tam toho prostě musí psát do komentářů neúměrně moc – zde bych velmi uvítal nějakou konvenci před konfigurací.

To, co jsi psal o těch code-templates v NetBeansech, zvýrazňování… to samozřejmě všechno lze vyladit. Ale mně osobně to přijde neúměrně pracné a zdržující. Navíc v tom nejsou žádné vyšlapané cestičky, a tak si člověk se vším musí pohrát sám. Já hledám nástroj, který mi bude sloužit, a ne něco, kvůli čemu budu ladit IDE, aby se to dalo alespoň nějak pohodlně používat. :)

To ani není účelem. Doctrine totiž svou podstatou degraduje databázi na pouhé relační úložiště.

A to mi právě přijde, že v případě 99,9% aplikací není nejlepší přístup (tím 0,1% jsou aplikace, které mají běžet na různých DBS a zároveň jim nestačí jen nějaká jednoduchá DBAL). Viz příspěvek od Edkeho. Dnešní databáze jsou mocné a je zbytečné suplovat jejich možnosti tak trochu neohrabaným způsobem někde jinde.

To není pocit, ale fakt. Otázkou je, jak moc velký je to problém.

No, je to problém takový filosofický, protože mi přijde, že něco, co si Doctrine 2 klade za úkol a mimo jiné i kvůli tomu je takový moloch, vlastně pořádně neřeší. :) Tak trochu patovka a já z toho cítím takový „neutěšený stav“.

Ať slouží ;)

Díky, uvidíme, jak dlouho vydrží :). V záloze mám kdyžtak právě tu celou business logiku v databázi, chci si to někdy minimálně vyzkoušet :).

Editoval Tharos (16. 8. 2011 22:45)

@jtousek: Když bylo vydáno Nette\Database, už jsem měl něco málo napsáno v NotORMu, takže jiné API Nette\Database pro mě bylo spíš nezvykem :). Nicméně když přišlo Nette\Database, měl jsem přirozeně tendenci přemigrovat, ale nakonec jsem si to hlavně ze dvou následujících důvodů rozmyslel (a ani dnes bych se nerozhodl jinak):

1. NotORM obsahuje možnost nadefinování vlastních vazebních konvencí. To jsem k mému vlastnímu překvapení v praxi už několikrát použil. Naposledy minulý týden :), kdy jsem databázi „dostal darem“ (doprogramovával jsem jenom jeden e-learning na subdoméně a část dat jsem tahal z již existující databáze). Jelikož ta databáze obsahovala výjimky oproti standardní konvenci (například sloupec parent namísto table_id a pár podobných), vážně se mi ta možnost hodila. Nevím, jestli by tohle v současné době v Nette\Database vůbec nějak šlo vyřešit.
2. Tohle je dost subjektivní, nicméně… NotORM má IMHO slušnou podporu (Jakub reaguje na dotazy de facto v řádech minut až hodin) a aktivně se vyvíjí. Nette\Database fandím, ale poslední vyloženě Davidovo (tj. autorovo) commity mají nějaký červnový datum a podpora je taková, že Ti zde na fóru na případné dotazy napíše Jakub, abys zkusil namísto jej použít NotORM, protože tam je problém XYZ už vyřešen. :)

Plus hlavně z poslední doby má NotORM pár užitečných nových vymožeností, u kterých si nejsem jist, jestli už je někdo portoval do Nette (ale tipuji, že nikoliv).

EDIT: Když si tu tak po sobě čtu, tak mám znovu tendenci upozornit na to, že nejsem zaměstnancem „NotORM foundation“ a jde skutečně pouze o slova spokojeného uživatele :).

Editoval Tharos (16. 8. 2011 21:19)

Tharos wrote:

@edke: Díky za tenhle post, to jsem přečetl na jeden dech :). Když ještě nebyl venku NotORM a já řešil modelové dilema, byl jsem rozhodnut jít přesnou touto cestou. Dodnes jsem přesvědčen, že se to v podstatě blíží ideálnímu řešení, ale tak nějak jsem si teď navykl na ten NotORM. :)

Ještě poznámka k tomu NotORM API – ono není tak magické, jak se zdá. Spíš se jen opravdu nepodobá ničemu jinému (snad možná jen SimpleXML má podobné API) a vůbec NotORM vyžaduje lehce specifický styl myšlení. Má zkušenost ale je, že rychle „vleze pod kůži“ a pak je vývoj nesmírně rychlý. Samozřejmě to ale nemusí tak být u každého.

V jednom vacsom projekte riesim ale situacie, kde mi NotORM nepomoze. Tu mi pomahalo Doctrine a jeho entita a teda pri hladani nahrady som musel na tento problem mysliet.

V spominanom projekte je databaza uloziste ako pre webove UI pre uzivatelov, tak pre zariadenia, ktore komunikuju s databazou cez socketovy server (zhodnou okolnosti tiez mnou po X-ty krat prepisany a napisany v PHP, nakoniec krasne funkcny a stabilny vdaka prestudovaniu zdrojovych kodov apache web servra a implementacii Semaphores in PHP).

Niektore properties ukladane do databazy je potrebne pre socketovy server prekladat do ciselnych interpretacii ale pre potreby Web UI zas do vyznamovych textovych. Napriklad power, ON a OFF ale pre potreby socketoveho servra 0×30 a 0×31. Toto samozrejme krasne v Doctrine mi riesila entita a konkretny getter a setter pre danu property. Ale aj tam boli situacie, ze danu property som obcas potreboval v jednej aj druhej podobe.

Samotny postgre mi tuto situaciu riesi elegantne. Pre interne ulozenie dat zvolim vlastny datatyp ako enum a potom podla potreby napisem cast functions, alebo rovno VIEWS spolu s castingom.

CREATE TYPE power AS ENUM
   ('on',
    'off');

CREATE TABLE device
(
  id serial NOT NULL,
  power power NOT NULL,
  CONSTRAINT device_pkey PRIMARY KEY (id)
);

CREATE OR REPLACE FUNCTION int4("value" power)
  RETURNS integer AS
$BODY$
  begin
    IF ( value = 'on'::power) THEN RETURN 48;
    ELSIF (value = 'off'::power) THEN RETURN 49;
    ELSIF (value = null) THEN RETURN null::integer;
    ELSE
    raise exception 'Unable to cast % to integer.', value;
    END IF;
  end;
$BODY$
  LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION power("value" integer)
  RETURNS power AS
$BODY$
  begin
    IF ( value = 48) THEN RETURN 'on'::power;
    ELSIF (value = 49) THEN RETURN 'off'::power;
    ELSIF (value = null) THEN RETURN null::power;
    ELSE
    raise exception 'Unable to cast % to power.', value;
    END IF;
  end;
$BODY$
  LANGUAGE plpgsql;

CREATE CAST (integer AS power)
  WITH FUNCTION power(integer)
  AS ASSIGNMENT;

CREATE CAST (power AS integer)
  WITH FUNCTION int4(power)
  AS ASSIGNMENT;

INSERT INTO device (power) VALUES ('on'), ('off');
INSERT INTO device (power) VALUES (48), (49);

CREATE VIEW device_for_sockets AS
 SELECT device.id, device.power::integer AS power
   FROM device;

select * from device;
 id | power
----+-------
  1 | on
  3 | on
  4 | off
  2 | off

select * from device_for_sockets;
 id | power
----+-------
  1 |    48
  3 |    48
  4 |    49
  2 |    49

Pekne, nie ? :)

Da sa ist dalej. Aby sa neduplikoval kod a samozrejme ze casto ciselnik je potrebne mat pristupny v aplikacii, pomoze funkcia, ktora vrati zoznam enum typu ako query result:

CREATE OR REPLACE FUNCTION get_power()
  RETURNS SETOF character varying AS
$BODY$
  declare
    value power;
  begin
    for value in select unnest(enum_range(null::power))
      loop
        value :=  cast(value as character varying);
        return next value as "name";
      end loop;
    return;
  end;
$BODY$
  LANGUAGE plpgsql;

select * from get_power();
 get_power
-----------
 on
 off

$options = $context->database->table(new SqlLiteral('get_power()'))
	->fetchPairs('get_power', 'get_power');
$form->addSelect('power', 'Power', $options);

V pripade multilingualnej aplikacie sa da pekne extraktovat takyto retazec (ak mame schemu verziovanu), ja pouzivam forknutu verziu gettext-extractor-a od autorov Karla Klimu a Ondřeje Vodáčeka, ktora sa da krasne rozsirovat podla potreby. Napriklad, aby parsoval .sql subory a hladal create types.

Milo wrote:

Třeba že INSERT/UPDATE/DELETE se dá dělat i na VIEW.

Hm, nad tymto som presne uvazoval, ze toto by sa zislo, uz som si zacal studovat RULES.

Mimo PL/pgSQL a PL/Perl(u) jsem koketoval i s PL/PHP (psaní uložených procedur v PHP). Sice se moc neosvědčil, ale zajímavá zkušenost.

Aj ja som nad tym uvazoval, ale myslim ze nie je dovod, PLPGSQL je dostatocujuce a hlavne PHP je vzdy interpretovane, rychlejsie urcite nie je.

Od verze (asi) 8.3 zpracování vyjímek v procedurách, velká pecka.

apgdiff je rozhodně dobrý nástroj, také jsem ho nějaký čas používal. Ale díky tomu, že Postgres využívám tak komplexně, po čase mi přestal stačit. Verzování řeším v podstatě jako ty. Diffy a celé schema pg_dumpem.

Ja som uz prisiel nato, ze napriklad TYPES apgdiff nepozna. Urcite to nebude kompletny nastroj, ale aspon pomoze s tymi jednoduchymi trivialnymi rozdielmi a zbytok rucne.

Místo pgAdmin mám ale koupený EMS SQL Manager for PostgreSQL. Je velmi intuitivní a za ten peníz to rozhodně stálo. Doporučuji zkusit trial verzi. Jednou z výhod je, že před jakoukoliv změnou schématu zobrazí odesílaný SQL dotaz.

Ja som ale na linuxe a nemam rad ani wine, ani virtualizaciu, nativne ak sa da. A pgAdmin mi staci. EMS SQL poznam, urcite ta pridana hodnota ako za komercny produkt sa prida. Ak by som bol na Win, isto by som si nejaky nastroj kupil. Zatial ale pgAdmin staci.

A ten si kopíruji do diffu.

Musim vyspekulovat, nejaky sql history log by sa pridal, isto by to pomohlo rychlejsie vyskladat diff patch.