Vlákno názorů k článku Migrace aplikace z Oracle do PostgreSQL od Ja..... - A čo tak popisať ako je riešený COMMIT,...
-
Ja..... (neregistrovaný)
A čo tak popisať ako je riešený COMMIT, rollback to savepoint, autonomna transakcia....
Niekde nejaky kravatak napisal ze je to izy... ved naco je rollback ved exception samo urobi rollback.. Inaksie este asi 100 dalsich zaujimavosti popisanych vlastnosti.. Napr. retazec NULL a "" nie je to iste, ale v oracle je to nulll, to znamená prekopat celu logiku.... -
ROLLBACKy, SAVEPOINTy jsou v Postgresu implicitní - dané strukturou - většinou stačí přizpůsobit blokovou strukturu kódu a pak v Postgresu je zakomentovat (je to v ToDo Ora2pg). COMMIT je v Postgresu také implicitní - v podstatě je to aplikační záležitost - pokud nedojde k chybě, tak při autocommitu se se commituje automaticky.
Záleží na důvodu proč v kódu používáte COMMIT - ve většině případů jej stačí pro migraci do Postgresu opět zakomentovat (Ora2pg to při migraci může udělat). V aplikaci, kterou jsem migroval se pouze v jediném případě nějak aktivně používal opakovaný COMMIT v procedůře - a bylo to z důvodu pádů příliš velkých transakcí na Oracle - což v Postgresu není problém, takže vnitřní COMMIT v proceduře jsme v Postgresu mohli ignorovat.
Ora2pg umí vyřešit i bezpečné porovnání na prázdný řetězec - nicméně výsledný výraz je výrazně delší, takže je jednoduší opravit kód na Oracle, tak aby se mohl 1:1 použít i na Postgresu - tj na Oracle nepoužívat prázdné řetězce, ale pouze NULL (v IF a pro jiné datové typy než je varchar). Je to asi masivní změna, ale dá se to udělat hromadně - takže i při statisících řádcích je to práce na pár pracovních dnů.
Netvrdím, že migrace aplikace, která často používá silně Oraclovské obraty je na lusknutí prstu - ale je realizovatelná - a kromě toho, že se připraví port do Pg, tak se i hlavně zásadně pročistí kód v PL/SQL.
Pokud by kód v PL/SQL (Oracle) byl napsaný podle moderních best practicies, tak pak migrace je docela jednoduchá. Když se použivají deprecated výrazy, obsolete funkce, tak je to výrazně pracnější - prvně je potřeba modernizovat (vyčistit) kód v PL/SQL a pak poté provést migraci.
V některých případech to může být pro uživatele, vývojáře příliš drahé - pak je alternativou EDB, kde jsou alespoň poloviční a nižší licenční náklady a je tam vrstva, která emuluje Oracle, anebo aplikace musí dožít na Oracle.
-
vasek (neregistrovaný)
"pak je alternativou EDB"
Nevím, jak se situace změnila, ale naše firma si před asi 6 roky myslela to samé, ale EDB byla tak nespolehlivá a plná chyb (a stejne neuměla vse co oracle a přechod byl velmi bolestivý), že ten přechod rovnou na čistý postgres (na který se nakonec stejně přešlo) by bývala byla lepší varianta.
-
EDB je v jádru Postgres - vrstva kompatibility s Oraclem není příliš tlustá - úplně emulovat Oracle nelze - ale nejčastější balíčky a PL/SQL emulují v zásadě dobře. Určitě je tam nějaký posun. Určitě ne každá aplikace poběží bez úprav na EDB, na druhou stranu těch úprav nemusí být zase až tak hodně.
