Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
zdravím,
mám několik desítek strojů a v každém z nich je mimo jiné jedna databáze s asi stovkou tabulek..
Poradí mi někdo nějaký jednoduchý nástroj, který mi zařídí, že když změním nějakou tabulku (přidám sloupec, či např. změním datový typ sloupce či defaultní hodnotu), aby se mi toto nové schéma tabulky změnilo i na ostatních strojích...
tyto stroje jsou offline, takže tento nástroj bych použil v nějakém skriptu, který bych musel na každým stroji spustit
díky za nějaký tipy
no tu databazi vytvarim v pgadminu..a nechce se mi kdyz upravim nejaky sloupec, abych to musel jeste davat do nejakyho vlastniho skriptu..pac vim, ze obcas proste neco zapomenu...
potreboval bych nejaky nastroj, ktery mi ten skript vygeneruje sam..resp. nejaky nastroj, ktery mi zaridi, abych mohl ty databaze na ostatnich strojich udrovat se stejnym schematem
ten update ostatnich stroju delam napr jednou za mesic a kolikrat je v ty databazi strasne moc zmen (novy tabulky, novy sloupce v existujicich tabulkach,....), a nekdy treba zadna zmena
neco jako udelat backup schematu do plain textu a pak ty create table zduplikovat a udelat z jednotlivych sloupcu alter table add column (sice by to hlasilo milion chyb, ale snad bych zaridil ze sloupce tam budou nakonec vsechny...)
no tu databazi vytvarim v pgadminu.hmm, 100 tabuliek, 10 strojov a samovražedné sklony k tomu?
mrkni na tohle:
http://www.postgresql.org/docs/8.4/interactive/continuous-archiving.html
pouziva se to pro zalohovani, vzdycky by sis ty wal soubory zazalohoval a jednou za cas pustil na ostatni databaze
tak sem to vyresil tak trochu krkolome a asi i nebezpecne..
1. zazalohuju celou puvodni databazi (to jen pro jistotu, kdyby nasledujici postup selhal)
2. zazalohuju jen data stare databaze
3. smazu vsechny tabulky v databazi
4. restoruju novou databazi, resp. nove schema (puvodni schema je vzdy podmnozinou - jelikoz o tom vim, tak si to proste ohlidam :)
5. restoruju puvodni data ...ty chybejici sloupce se doplni defaultnima hodnotama
je to trosku hnusne vyresene, ale provede to presne to co potrebuju :)
To je dost sileny. Milionkrat lepsi, inteligentnejsi, konzistentnejsi, bezpecnejsi a obvyklejsi reseni je, jak rikal jiz kolega vyse, proste si pripravit SQL skript kterej poustis na testovacim stroji a pripadne modifikujes dokud neudela to co chces, a pak ho pustis na vsech ostatnich.
a pak ho pustis na vsech ostatnich.
A já se modlím i u tohoto kroku.
ALTER skripty je nejlepší psát v ruce - pak víte, co obsahují. Navíc v PostgreSQL lze alter skript obalit transakcí. Tudíž, když někte v půli spadne, tak se vůbec nic neděje. Tj.
BEGIN
ALTER TABLE foo ADD COLUMN boo integer;
COMMIT
Není nic jednoduššího, než ještě mezi vývojové prostředí a produkční vložit jedno, které je obrazem produkčního. A předtím než něco nasadím na produkci, tak to tam testnout.
BTW: neznáš nějaký testovací nástroj na porovnání dvou databází (jen model, ne data)? Něco na způsob: udělám dump (jen schématu) obou DB, odfiltruji komentáře (obsahují např. datum, nebo jiné věci, které se mohou měnit) a porovnám je.
Prostě pro kontrolu, abych měl jistotu, že ten skript s ALTER a CREATE… příkazy dělá přesně to, co chci.
Porovnání schémat umí třeba SQL Developer (měl by jít přes JDBC driver napojit na libovolnou databázi). Ale není to nic moc. Asi vůbec "nejjednodušší" je vylejt schémata do skriptů a porovnat klasickým diff
em.
jj, to můžu udělat, ale zajímalo mě, jestli už existuje nějaké hotové řešení
Vážně ten výpadek (tzn. to že od bodu 1 k bodu 5 má kdokoli utrum s přístupem k databázi) stojí za ušetřených pár minut při psaní alteru?
Jak již tady někdo poradil. Já jsem na Sybase ASA také používal tu metodu, že jsem si nechal vždy přeložit log databáze do SQL, v něm jsem scriptem našel všechny potřebné DDL příkazy a z toho sestavil upgrade dávku.
Druhá možnost, která existuje, je najít nějaký nástroj na porovnání dvou DB, který by uměl vyrobit příslušný rozdílový scrip. Na to jsem používal nějaký předpotopní program dbdiff.exe (pro windoze), který se pomocí ODBC rozhraní připojil ke dvěma DB a vygeneroval rozdílový SQL script.
To co jste nakonec udělal, zkombinovat data ze staré DB s DDL z nové DB, do toho bych nešel, pravděpodobně Vám to funguje čirou náhodou
Dokud nebudeme mít použitelnou AI, tak to za tebe nikdo neudělá.
Ale, ale! Vygenerovat DDL na základě rozdílu (MINUS
) user_tables
, user_tab_cols
, user_indexes
či user_partitions
zvládne snad každý, ne?
Vytvoření sloupce před indexem je snad základ, ne?
Migrace dat je ovšem jiná pohádka.
Migrace dat je v tomhle případě přesně ta stejné pohádka, ne? Když už má autor původního ten zvláštní přístup, že raději na 10 strojích provede dump+dropdb+createdb+create_schema+load_data než aby si ručně napsal 5-řádkový alter skript, tak bych se dost divil kdyby se po přidání sloupečku chtěl sám starat o migraci dat
Migrace dat je ovšem jiná pohádka.A právě tahle pohádka je důvod, proč automatika nestačí
Zkusil bych pouzit Apachi DDLUtils. Jsou relativne pomale, ale spolehlive.
http://db.apache.org/ddlutils/
Tiskni
Sdílej: