Ale jo, management command není problém. Jak už se do toho člověk pustí, tak udělá cokoliv.
Chápu, že databáze je jen další storage, ale je tam “analogie” se soubory media a static. Media jsou od uživatelů, říkejme dynamická, i když to zní blbě. Oproti tomu static soubory jsou součástí aplikace a musí tam být. Každé volání collectstatic zkontroluje, jestli tam jsou a jestli jsou nejnovější. Něco podobného jsem chtěl i pro “statická” data v databázi. Na jednu stranu jsou tam data od uživatelů, např. články, blogy, fotky. Pak jsou tam i “systémová” data, viz auth tokeny, atp. Potřebuji tyto data pravidelně kontrolovat a případně aktualizovat. Vtip je i v tom, že v jedné tabulce můžou být spolu jak statická, tak dynamická data, např. přihlášení uživatelé vs. superuser. To označení statická/dynamická dost kulhá, jestli máte někdo variantu, sem s ní :) Tom V 22. října 2014 at 10:39:39, Věroslav Kaplan ([email protected]) napsáno: Ahoj, na starém W4PY bylo možné spouštět nějakou inicializaci při startu aplikace - používal jsem to třeba pro synchronizovaci externích dat, apod. Na Djangu to nejspíš tak lehce nejde (napadá mne wsgi, které se vlastně tak úplně nespouští, můžešme mít více workerů, apod). Nedalo by se to řešit jako management_command - třeba "update_magic_data", který bys při deploy aplikace pouze spouštěl? Ocenil bych i elegantnější řešení, ale taky mne nic nenapadá. --Věroš 2014-10-22 10:31 GMT+02:00 Tomáš Ehrlich <[email protected]>: ad 2) Právě proto, že se “blbě” migrují mezi prostředími. Blbě = chybí mi chytrý workflow ad 3) Pokud chceš ušetřit čas, tak transifex, spousta dalších služeb, pootle, atp. tohle dělají. Pokud ne, tak si to napiš sám, taky to mám rozpracované :) Tom V 22. října 2014 at 9:50:32, Jan Češpivo ([email protected]) napsáno: Ahoj, 1) Měj vždy někde uložená normalizovaná data. Různé CSVFields, ListFields nebo JSONfields apod. tě nakonec vždycky nějak vypečou. Když už, tak např. PostgreSQL má k dispozici typ jsonb. Pokud už někde potřebuješ mít denormalizovaná data, tak ta musí být vždy závislá na těch v normální formě, ne naopak. 2) Proč nemůžeš mít statické informace také v DB? Je to normální uložiště. Jediný typ dat, na který se nehodí, jsou binární soubory (a to asi také neplatí vždy). 3) .po soubory jsou takový zvláštní případ, řešíme je prakticky neustále, špatně se mergují z více větví atd.. Stay tuned, velmi brzy se na githubu objeví projekt nahrazující django-rosetta, který překlady ukládá do db a .po soubory jen generuje, případně importuje ;) H. 2014-10-21 12:31 GMT+02:00 Tomáš Ehrlich <[email protected]>: Zdar, poslední dobou chodím kolem dokola stále stejného problému: a) mám určitá data, která se mění opravdu vyjímečně… klidně bych je mohl mít někde v settings b) potřebuju je mít v DB, protože se snadněji řeší relations c) závisí na nich chod aplikace — musím pravidelně ověřovat, jeslti tam jsou a případně je obnovit d) potřebuji je překládat do více jazyků Příklady: - django.sites - auth tokeny (django-allauth) - šablony emailů - atributy produktů, atp ad a, b) Zkoušel jsem ty data hodit i mimo db a přiřazovat je objektům pomocí comma separated fieldů, ale pak na to potřebuji navazovat další věci a už to začíná být moc komplikované. Klasické relace vyhrávají. ad c) Dřív to “řešili” initial data, která se načetly po každém syncdb. Upravil jsem si vlastní skript, který obnovil do výchozího nastavení pouze ty data, která chybí (podle primary/unique klíče). Těd jsou nové migrace, takže initial_data odpadají (provedou se jen jednou při spuštění migrace). ad d) Není problém, jak to nacpat do databáze. Problém je synchronizace překladů s centrálním úložištěm, ať už je to služba typu transifex nebo .po soubory. Nemůžu pořád myslet na to, že část webu je přeložená na jedno místě a zbytek v databázi. Řešíte to nějakým elegantním způsobem? Jediné co mě napadá udělat si vlastní appku, říct jí které modely obsahují “statická” data a ty pak a) synchronizovat s překlady, b) kontrolovat, jestli obsahují všechny data, která potřebuji. Ale znáte to. Nová appka = spousta práce a možná existuje jiné, lepší řešení :) Tom -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ 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 [email protected]. Další možnosti najdete na https://groups.google.com/d/optout. -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ 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 [email protected]. Další možnosti najdete na https://groups.google.com/d/optout. -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ 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 [email protected]. Další možnosti najdete na https://groups.google.com/d/optout. -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ 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 [email protected]. Další možnosti najdete na https://groups.google.com/d/optout. -- -- E-mailová skupina [email protected] Správa: http://groups.google.cz/group/django-cs --- Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 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 [email protected]. Další možnosti najdete na adrese https://groups.google.com/d/optout.
