problémy s funkcionalitou extenzí

[Ivo Kohn]

Ahoj,

už nějakou dobu vyvíjíme aplikace pomocí extenze (čistě sql). Nevím, jak moc je to standardní postup, ale objevili jsme pár drobností, které nám trochu komplikují život:

1) Řekněmě, že vytvořím v extenzi skripem extension--1.0.0.sql schéma a nějakých pár tabulek. Zavoláním pg_extension_config_dump tyto tabulky označím jako "tabulky s dynamickými daty", tedy daty, které plní user a které musí mít možnost dumpovat. Vydumpovat pak samozřejmě jdou, pokud pg_dump zavolám na celou databázi, nebo s přepínačem --table na konkrétní tabulku. Bohužel, přepínač --schema již nefunguje. To je problém v případě, že máme více extenzí na jedné databázi a každá má své "user tabulky" ve svém schematu. Chtěl bych dumpovat každou extenzi zvláště aniž bych musel držet seznamy tabulek jednotlivých extenzí. Naprosto parádní věc by byla existence přepínače --extension.

2) Je super, že jde do souboru .control označit další extenze, na které ta právě vyvíjená závisí. Super už moc není, že nelze s dalším patchem (changeskriptem např. extension--1.0.1--1.0.2.sql a ve stejný moment upraveným requires v .control) tuto závislost odstranit. Nelze jinak, než data vydumpovat, vytvořit novou verzi extension--1.0.2.sql a data restorovat. Taky je škoda, že nejde specifikovat číslo verze závisející extenze.

3) Taková kosmetická věc, ale po přidání tabulky do pg_extension_config_dump a jejím následném odstranění zůstave viset v ext_config její OID.

Máte s těmito problémy nějakou zkušenost? Případně, jak tyto požadavky formulovat někam blíže k vývojářům mechanismu extenzí?

I.

[Pavel Stehule]

Ahoj

čt 3. 1. 2019 v 9:17 odesílatel Ivo Kohn <kohn...@gmail.com> napsal:

Z toho, co tu píšeš mi něco přijde jako nepodporované (dosud nenaimplementované) vlastnosti a něco jako chyby. Implementačně by to nemělo být nijak zvlášť náročné - tohle je +/- aplikační kód, který je poměrně jednoduchý.

Jelikož se jedná o zásah do core - tak by ses měl obrátit do mailing listu https://www.postgresql.org/list/pgsql-hackers/ a poslat návrh řešení, případně patche. Chyby asi by někdo opravil, ale novou funkcionalitu obvykle musí napsat ten, kdo ji požaduje - má největší motivaci, a také typicky o daném problému nejdéle a nejintenzivněji přemýšlí. S případným patchem můžu pomoct. Myslím si, že implementace přepínače --schema, --extension by se mohla ještě stihnout do 12ky.

Pavel

 

I.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Další možnosti najdete na https://groups.google.com/d/optout.

[Jan Michálek]

Zajímavý

No, já si taky tu datovou část aplikace držim v extenzi. Myslim si, že to je na to ideální.

K tomu dumpu, no, popravdě chování pg_dumpu s kombinováním -n -t a případně někdy taky hvězdiček mi přijde občas krapet zmatečný (respektive ne uplně intuitivní, nedělá to vždy to, co bych očekával), zvlášť, když teda nemam stejnou verzi postgre na servru a na klientu, odkud dumpuju. Vždycky si radši kontroluju, co to teda zadumpovalo a občas se divim. ALe možná je chyba u mě.

Ale všiml jsem si, že když spatial_ref_sys (kam extenze postgis ukládá definice souřadnicovejch systémů) přidam svuj vlastní, tak v dumpu je akorát ten jeden přidanej řádek ()respektive, je to delší dobu, co jsem si too všim, už nevim, co jsem měl za verze, nevim, jestli to dělá furt). Což je správně. Už jsem si několikrát řikal, že se podivam, jak je to tam udělaný. Takže bych doporučil začít výzkumem tady a podivat se, jak to maj udělaný a co to teda dělá.

Jinak, co k čemu patří najdu v pg_depend.

A teda, víc stejnejch extenzí v jedný db. už jsem o tom uvažoval, ale pak jsem to zavrhnul, nepřišlo mi to uplně prozíravý.

Je;

Je;

čt 3. 1. 2019 v 8:35 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

--

Jelen

Starší čeledín datovýho chlíva

[Ivo Kohn]

Díky pánové za odpovědi.

Nevím, jestli by nějaký patch do Postgresu pro mě nebyl velké sousto, v C neumím téměř nic, ale každopádně to zní zajímavě. Pokusím se do toho mailing listu reportovat chyby a to ostatní uvidíme.

Co se týče dumpu z Postgisu, funkce pg_extension_config_dump přejímá jako druhý parametr text, kde je specifikována WHERE podmínka, kterou na dumpované tabulce pg_dump uplatní (viz. cca čtvrtý odstavec https://www.postgresql.org/docs/11/extend-extensions.html#EXTEND-EXTENSIONS-CONFIG-TABLES). Zkontrolovat to jde zavoláním SELECT * FROM pg_extension. Jsou tam ve sloupci extconfig vidět OID dumpovatelných tabulek a u postgisu v extcondition taky podmínka WHERE NOT ... a snad všechen SRID, co v tabulce spatial_ref_sys je. Z výše uvedeného soudím, že to nemá nic moc společného s chováním pg_dump v souvislosti s přepínačem --schema.

Nevidíme zatím žádný problém v tom mít více extenzí v jedné DB, ale zatím s tím nemáme toliko zkušeností, abych tohle řešení stroprocentně obhájil. Vývojově i funkčně se jedná o poměrně samostané věci, které ale zároveň na sebe navazují a jedna z druhé čas od času čerpá data. Pokud je to na stejném železe, neviděli jsme žádnou výhodu v tom to mít v jiné DB, spíš by to komplikovalo situaci (nutnost vytvářet FDW apod.).

Ivo.

Dne čtvrtek 3. ledna 2019 12:52:23 UTC+1 mluvicí hrášek - jeleniste napsal(a):

[Jiří Fejfar]

Ahoj,

asi by bylo nejlepší začít těmi jednoduchými věcmi, kde bychom mohli očekávat, že se toho chytí vývojáři?

3) visící OID v ext_config

2) ty věci se závislostmi (to zas tak jednoduché nebude?)

4) nemožnost změnit vlastníka extenze (pozn.: to přidávám, s Ivem jsme se o tom bavili)

ten bod 1) bychom si možná mohli nechat ještě vykrystalizovat a probral ho ještě tady?:

1a) upravit chování přepínače --schema, aby zafungoval jak si představujeme: tj. vydumpoval vše ze schématu, i tabulky patřící extenzi, které jsou označeny pomocí pg_extension_config_dump (v dokumentaci jim říkají "Extension Configuration Tables", já bych asi řekl tabulky obsahující uživatelská data).

Nejsem si úplně jistý, jestli to, že se data těchto tabulek nedumpují je chyba, nebo je to nějaký záměr, který si neuvědomujeme. Už podle toho názvu "configuration tables" mi připadá, že ten záměr těch tabulek nebyl asi úplně stějný, jak je my používáme teď: tj. tabulky, kde jsou uživatelská data, která jsou uživatel od uživatele jiná, proto jim taky říkáme tabulky s "dynamickými" daty -- na rozdíl od "statických dat" kde očekáváme, že budou pro všechny uživatele/instalace stejná.

Např. zmíněné spatial_ref_sys je hybryd, kde je statická část, která je postGIS od PosGISu (v dané verzi) stejná ale pokud tam uživatel přidá svůj refernční systém, tak je ten považován už za dynamický/konfigurační nebo jak tomu říct a je tedy vydumpován (jak vysvětloval Ivo správně, v souladu s dokumentací)

pod "konfigurací" by si člověk asi představil něco trochu jiného, ne? Ale zase konfiguraci dělá uživatel, tj. jsou to jeho specivické záznamy... takže vlastně to tak daleko není.

A navíc pokud se tato data dumpují s přepínačem --table tak by se to asi mělo chovat stejně s přepínačem --schema, že? Takže asi spíše chybné chováni?

1b) přidat nový přepínač --extension: ten by vydumpoval všechny "Extension Configuration Tables" tabulek patřící extenzi. Tady by chtělo asi popsat Use Case, pro který se toto hodí: mám extenzi, která obsahujě nějaká data, která mohu chtít případně použít odděleně i jinde?

s tím Cčkem bych možná byl schopný pomoci.

Mějte se, Jura.

[Pavel Stehule]

pá 4. 1. 2019 v 8:20 odesílatel Jiří Fejfar <juraf...@gmail.com> napsal:

Ahoj,

asi by bylo nejlepší začít těmi jednoduchými věcmi, kde bychom mohli očekávat, že se toho chytí vývojáři?

Tam není komplikovaný kód - jde jen o to, dobře vysvětlit, prezentovat svoje potřeby.

Myslím si, že lidé kolem PostGISu tuhle problematiku dost intenzivně řeší - a zároveň jsou docela komunikativní, takže zkuste je oslovit - třeba pak prostřednictvím pg_hackers.

Zároveň na nějaké otázky ohledně návrhu by Vám mohl odpovědět Dimitri, který je za návrhem a i realizací extenzí, docela pohodový chlap -  https://github.com/dimitri

3) visící OID v ext_config

2) ty věci se závislostmi (to zas tak jednoduché nebude?)

Je to jen o zavedení systému verzí (nebo rozšíření stávajícího) a jeho parsování - jelikož jsou to jen dvě tři čísla, tak nic těžkého - zbytek udělá SQL

 

4) nemožnost změnit vlastníka extenze (pozn.: to přidávám, s Ivem jsme se o tom bavili)

Určitě je dobré začít chybama - ať už těmi zřejmými nebo možnými, kdy to není patrné.

[David Turoň]

Ahoj,

ja jen dopisu nase zkusenosti, nijak ti to asi nepomuze v reseni problemu. Extenze aktualne pouzivame spis pro mensi knihovny a male projekty, casto nas u aplikaci trapilo nejake omezeni u extenze. Od te doby prosly extenze mnoha inovacemi, tak nektere problemy uz mozna pominuly. 

Na velke projekty jsme si vyvinuli system pro spravu a instalaci verzi, fungujici podobne jako extenze. Projekt si udrzujeme rozdeleny na soubory s tabulkama, funkcema, indexy a podobne (podobny vystup ma tool pg_extractor) - ale pri vydani verze se generuje jeden SQL soubor na zaklade definicniho souboru s poradim instalace. Upgrady se uz lisi, mohou se skladat z vice souboru (transakcni a netransakcni), nekdy staci ten transkcni soubor, ale jindy je potreba delat neco co postgres nemuze delat v transakci... typicky pridani hodnoty do ENUM, CREATE INDEX CONCURRENLY apod.

Zavislosti si hlidame pomoci klasickych zavisosti v RPM, definice roli je v definicnim souboru - vytvori se automaticky po instalaci s vygenerovanymi hesly pokud jde o LOGIN roli

Upgrady se generuji poloautomaticky - na zaklade git zmen mezi verzema.

S vyvojem jsem zacal tady (resil ciste jen tvorbu vysledneho SQL souboru a pripravu upgrade skriptu)

https://github.com/dturon/sql_projects_template

https://docs.google.com/presentation/d/1id_yREEOI8-BDop_Z4jCtSnZNy89Pq9q3Pe6d9JMEgQ/edit?usp=sharing

ale pozdeji si kolega prevzal vyvoj a vznikl mnohem robustnejsi nastroj zahrnujici prave instalaci i vytvareni roli, ktery mozna firma uvolni :)

Proti extenzim to ma sve vyhodi i nevyhody ... jako nevyhoda muze byt ze nemame vlastnictvi objektu k projektu jako u extenze. Ale data tabulek se normalne dumpuji, neni treba nic nastavovat. Projekty obvykle jsou s vice schematy, casto se i prolinaji schemata mezi projekty.

Taky nevim jesli to je spravny smer, ale usetrilo nam to nekolik starosti navic:) Nektere projekty maji 100 a vice instalaci. 

David

čt 3. 1. 2019 v 9:17 odesílatel Ivo Kohn <kohn...@gmail.com> napsal:

Ahoj,

--

[Michal Kozusznik]

Ahoj

Zminil ses, ze udrzujete soubory dle typu objektu. Chapu to tak, ze udrzujete soubory s na priklad CREATE TABLE ...

Pokud ale potrebujete updatovat db, pak je k tomu nutny ALTER TABLE ...

Jak jste si s tim poradili? Pisete rucne oba konstrukty?

My prozatim v souborech udrzujeme jen funkce se syntaxi CREATE OR REPLACE. Funkce extrahujeme z rucne napsaneho update scriptu pomoci utilitky. Diky tomu mame moznost verzovat ty funkce v GITu, a pak pripadne resit konflikty apod. V pripade objektu, kterych syntaxe pro vytvoreni a modifikaci je rozlisna, uz to tak nejde. Slysel jsem o pokusech udrzovani modelu db v metadatech, a pak generovani create nebo update scriptu na zaklade vysledku porovnavani dvou verzi metadat. Dokonce pred asi 6 lety, nekdo se nam chlubil udrzovani meta-dat v XML souboru a rucni jeho modifikaci.

Porad to ale vypada na obrovsky over-head.

Diky

MK

Dne čtvrtek 10. ledna 2019 11:47:31 UTC+1 David Turoň napsal(a):

[David Turoň]

Ahoj, 

funkce piseme taky s CREATE OR REPLACE, ty se dosadi automaticky, pripdane se k nim doplni hint na DROP, pokud se zmenil jejich vystupni format. 

U tabulek delame jeden soubor s CREATE TABLE.... pri zmene se do upgrade automaticky akorat vlozi HINT s ALTER TABLE table_name a vystup git diffu toho souboru s tabulkou. Je tam hodne variant, a prostor odladit to uplne na vse by bylo komplikovane. Na druhou stranu zmeny tabulek nejsou tak caste jako zmeny ve funkcich. Kazdopadne pred vydanim release zkontroluji jestli instalace nove verze sedi se starou verzi aktualizovanou s upgradem - to mam jako pojistku ze jsem nic nezapomel zahrnout do upgrade skriptu.

David 

čt 10. 1. 2019 v 14:44 odesílatel Michal Kozusznik <maxym...@gmail.com> napsal:

[Jiří Fejfar]

Ahoj,

my jsme se původně snažili také v gitu verzovat "CREATE" soubory. Později po poradách s Pavlem a studiu principů Evolutionary Database Design [1][2] (btw. nenašel jsem nějakou vyčerpávající knihu / web na toto téma) jsme usoudili, že je lepší vzít nějaký stav databáze, udělat dump --schema-only (v1.0) a pak verzovat pouze "changescripty" tj, "ALTER" kód. Overhead tam není téměř žádný. Po krátkém testování Flyway jsme zůstali u extenzí jako nástroje pro správu.

* aktuální CREATE kód pro objekty si můžu kdykolik nechat udělat dumpem --schema-only ...

* ostrou DB povyšuju pomocí těchto verzovaných changescriptů

* pokud chci udělat další instalaci, tak se vlastně nainstaluje do verze 1.0 a aplikuje se série changescriptů až do požadované verze.

    * toto se děje na prázdné DB (bez dynamických dat, viz dále), takže to nemusí nějak trvat

    * extenze umožňuje CREATE EXTENSION abc VERSION 1.X -- takže uživatel o tom v podstatě ani nemusí vědět

* pokud předešlý krok trvá dlouho (nebo testy trvají dlouho), udělám tzv. "baseline dump" vytvořím opět pomocí dump --schema-only (+ nějaké další kroky, to tu nebudu komplikovat) nový skript s "CREATE" kódem (v.2.0) a pokračuju stejně

* jedinou výjimkou jsou funkce a pohledy, hrozí zde že při mergi nějaké větve (kde se changescript připravuje) se přepíše mezitím aktualizovaná funkce / pohled verzí která vychází ze starší verze

    * funkce a pohledy verzujeme v samostatných souborech (tzn. při merge vznikne konflikt, pokud se verze v masteru -- resp. v ostré DB mezitím změnila)

    * kód funkce / pohledu vkládáme do changescriptu, na místo dané zakomentovanou značkou [3], automaticky jednoduchým vlastním nástrojem [4] (možná by se dalo taky nějak "zabudovat" přímo do extenzí)

* je třeba rozlišovat statická vs. dynamická data

    * statická data

        * se neliší mezi instalacemi a jsou součástí (jejich INSERT) verzovaného SQL kódu

        * jsou typicky malá

        * např. spatial_ref_sys postgisu (bez záznamů, které potenciálně vloží uživatel)

    * dynamická data

        * se mezi instalacemi liší, "vlastní" je zákazník

        * přenášejí se pomocí dumpů --data-only (tohoto se týkají Ivovy poznámky v prvním mailu tohoto vlákna)

        * v extenzích se označují jako "extension configuration tables"

        * pozn.: changescript povyšuje (transformuje) i tyto dynamická data, dump dynamických dat odpovídá vždy nějaké verzi extenze

Celý postup sedí na koncept extenzí -- líbí se nám, že zákazník (v našem případě spíš spolupracující organizace) instaluje naši extenzi pomocí standardního nástroje, který je součástí (a je dokumentovaný) přímo s postgresem. Součástí je i mechanizmus testů.

 
[1] https://en.wikipedia.org/wiki/Evolutionary_database_design
[2] https://www.martinfowler.com/articles/evodb.html

[3] https://gitlab.com/jurafejfar/sandbox/blob/master/extension_sandbox/sandbox--1.0.1--1.0.2.sql#L2

[4] https://gitlab.com/jurafejfar/sandbox/blob/master/chscrip_templ_conv.py

Jura.

[Jiří Fejfar]

On Thu, 3 Jan 2019 at 09:17, Ivo Kohn <kohn...@gmail.com> wrote:

Ahoj,

už nějakou dobu vyvíjíme aplikace pomocí extenze (čistě sql). Nevím, jak moc je to standardní postup, ale objevili jsme pár drobností, které nám trochu komplikují život:

1) Řekněmě, že vytvořím v extenzi skripem extension--1.0.0.sql schéma a nějakých pár tabulek. Zavoláním pg_extension_config_dump tyto tabulky označím jako "tabulky s dynamickými daty", tedy daty, které plní user a které musí mít možnost dumpovat. Vydumpovat pak samozřejmě jdou, pokud pg_dump zavolám na celou databázi, nebo s přepínačem --table na konkrétní tabulku. Bohužel, přepínač --schema již nefunguje. To je problém v případě, že máme více extenzí na jedné databázi a každá má své "user tabulky" ve svém schematu. Chtěl bych dumpovat každou extenzi zvláště aniž bych musel držet seznamy tabulek jednotlivých extenzí. Naprosto parádní věc by byla existence přepínače --extension.

tak pročítám Pavlův článek https://www.root.cz/clanky/postgresql-14-nove-funkce-nastroje-a-interni-optimalizace/ a ejhle!

pg_dump má nový přepínač -e případně --extension, kterým lze exportovat pouze vybranou extenzi.

kdo to zařídil? Díky! :-)

 

2) Je super, že jde do souboru .control označit další extenze, na které ta právě vyvíjená závisí. Super už moc není, že nelze s dalším patchem (changeskriptem např. extension--1.0.1--1.0.2.sql a ve stejný moment upraveným requires v .control) tuto závislost odstranit. Nelze jinak, než data vydumpovat, vytvořit novou verzi extension--1.0.2.sql a data restorovat. Taky je škoda, že nejde specifikovat číslo verze závisející extenze.

3) Taková kosmetická věc, ale po přidání tabulky do pg_extension_config_dump a jejím následném odstranění zůstave viset v ext_config její OID.

Máte s těmito problémy nějakou zkušenost? Případně, jak tyto požadavky formulovat někam blíže k vývojářům mechanismu extenzí?

I.

--

[Tomas Vondra]

On 5/24/21 9:39 PM, Jiří Fejfar wrote:

On Thu, 3 Jan 2019 at 09:17, Ivo Kohn <kohn...@gmail.com> wrote:

Ahoj,

už nějakou dobu vyvíjíme aplikace pomocí extenze (čistě sql). Nevím, jak moc je to standardní postup, ale objevili jsme pár drobností, které nám trochu komplikují život:

1) Řekněmě, že vytvořím v extenzi skripem extension--1.0.0.sql schéma a nějakých pár tabulek. Zavoláním pg_extension_config_dump tyto tabulky označím jako "tabulky s dynamickými daty", tedy daty, které plní user a které musí mít možnost dumpovat. Vydumpovat pak samozřejmě jdou, pokud pg_dump zavolám na celou databázi, nebo s přepínačem --table na konkrétní tabulku. Bohužel, přepínač --schema již nefunguje. To je problém v případě, že máme více extenzí na jedné databázi a každá má své "user tabulky" ve svém schematu. Chtěl bych dumpovat každou extenzi zvláště aniž bych musel držet seznamy tabulek jednotlivých extenzí. Naprosto parádní věc by byla existence přepínače --extension.

tak pročítám Pavlův článek https://www.root.cz/clanky/postgresql-14-nove-funkce-nastroje-a-interni-optimalizace/ a ejhle!

pg_dump má nový přepínač -e případně --extension, kterým lze exportovat pouze vybranou extenzi.

kdo to zařídil? Díky! :-)

 

Guillaume Lelarge z Dalibo (https://twitter.com/g_lelarge)

T.

2) Je super, že jde do souboru .control označit další extenze, na které ta právě vyvíjená závisí. Super už moc není, že nelze s dalším patchem (changeskriptem např. extension--1.0.1--1.0.2.sql a ve stejný moment upraveným requires v .control) tuto závislost odstranit. Nelze jinak, než data vydumpovat, vytvořit novou verzi extension--1.0.2.sql a data restorovat. Taky je škoda, že nejde specifikovat číslo verze závisející extenze.

3) Taková kosmetická věc, ale po přidání tabulky do pg_extension_config_dump a jejím následném odstranění zůstave viset v ext_config její OID.

Máte s těmito problémy nějakou zkušenost? Případně, jak tyto požadavky formulovat někam blíže k vývojářům mechanismu extenzí?

I.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Další možnosti najdete na https://groups.google.com/d/optout.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CA%2B8wVNWW5nCU07d-eDGw6oCcmrC-NJWNpvXKKV%3DaWPn%2Bkc1EXA%40mail.gmail.com.