Re: [django-cs] Přepínáni hlavní databáze

[Pavel Cisar]

Ahoj,
osobne kdyz uz mam pro kazdeho jinou db, tak bych rozjel vic instanci
aplikace s jinou konfiguraci prostredi (db). Prijde mi to lepsi nez delat
nejaky db routing peklo podle requestu.

Mej se

Pavel


ne 7. 11. 2021 v 12:46 odesílatel Vladimír Macek  napsal:

> Ahoj,
>
> prosím o praktické zkušenosti.
>
> Jde o Django apku, kterou chcete poskytovat více zákazníkům, každý budou
> mít svojí doménu. Zákazníků může být hodně a chci relativně jednoduché
> zakládání. Apka poběží jedna, víceprocesově jednovláknově.
>
> Zvažuju to tak, že svoje data bude mít každý zákazník v extra Postgresu.
> Má
> to výhodu, že zákazníci jsou datově bezpečně izolovaní, Postgres může
> běžet
> i u nich, můžou si kdykoli db odnést bez vypreparovávání (exportu) jako v
> klasickém multi-tenantu.
>
> Možnosti přepínání vidím per request, a to buď přepínání celé `default`
> databáze NEBO Django db routing. Při změně schématu by se musely zmigrovat
> všechny db.
>
> Vidím v tom výhody, ale rád bych se vyhnul slepým uličkám. :-)
>
> Pokud jste tou cestou šli, tak kde jste narazili a jak jste to vyřešili?
> Nebo jste přepínání db/routing per client opustili?
>
> Díky,
>
> Vláďa
> tel. 608 978 164
>
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> 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 django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/728c3708-d6b4-9d72-4c36-1951bc5271dc%40sandbox.cz
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
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 django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAKtEf97zv_Z8tAEhJCkwWBM29f%2B%2BcO46wZ2W-Tk4uHDvH3QJGQ%40mail.gmail.com.

Re: [django-cs] memcache + reload uwsgi náhodné errory

[Pavel Cisar]

Ahoj,
neni ten objekt vetsi nez maximum 1MB? Jinak to je chyba, kdy obvykle
pymemcache nerozumi odpovedi z memcache.
https://github.com/pinterest/pymemcache/blob/9e2451a3831e216ce726bf2b12f6a68d61e5cbb6/pymemcache/exceptions.py#L31

Pavel

st 4. 8. 2021 v 22:47 odesílatel Jan Munclinger 
napsal:

> Ahojte všichni!
>
> Problém:
> Po reloadu uwsgi vassala končí *náhodně* načítání dat z Memcached errorem
> MemcacheUnknownError.
>
> Detaily:
> Jedná se o zacachovanou instanci modelu, který má mimo jiné několik
> TextFieldů, kam uživatěl zadává delší texty (včetně nových řádků) anebo
> kusy JS kódu (např. nějaké JavaScriptoviny, ktere se pak vlepí do stránky).
>
> Memcached používám jinde bez problémů, ale právě tento - řekl bych že
> hodně "velký" objekt - má problém.
>
> V error hlašce vidim vždy nějaký kousek těch dat, např. z toho Textfieldu.
>
> Můj tip:
> Myslím, že nové řádky nebo velikost toho objektu, který chci zacachovat je
> problem. Nějaké bufferování, když se snaží "python" načíst data z
> memcached, nebo co já vím?
>
> Ale proč se to děje právě při reloadu uwsgi?
>
> Konfigurace:
> Memcached 1.5.6
> Python 3.6.9
> Django 3.2.5
> pymemcache  3.5.0
> backend: django.core.cache.backends.memcached.PyMemcacheCache
>
> Nemá někdo tip, čím by to mohlo být?
>
> Díky
> Mokys
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> 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 django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAKhpuXxjizu_yA0dg%3DFXEorCum2AnbzoJNzjc0gPyrQfWFn9KA%40mail.gmail.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
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 django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAKtEf96CQLobuOkbQygewDXYkXT%3DTXpdOpVPQHN97T%2Bd1jqHFQ%40mail.gmail.com.

Re: [django-cs] Přejmenování objektů v ModelForm

[Pavel Cisar]

Zdravim,
tak bych si predefinoval choices pro ten konretni field. Neco jako.

*form.fields["coursedate"].queryset =
CourseDate.objects.filter(id__in=seznam).order_by('date_start’)*
*form.fields["coursedate"].widget.choices= [(d.id ,
d.get_custom_name()) for d in  form.fields["coursedate"].queryset]*

Nevim, jestli je field povinny, takze pripadne pridat jeste empty value.
Mozna je neco elegantnejsiho, ale tohle by mela byt taky cesta.

Hodne zdaru

Pavel



so 10. 4. 2021 v 21:30 odesílatel Stanislav Vasko 
napsal:

> Zdravím,
>
> asi už blbnu nebo prostě to nevidím, ale nemohu najít cestu, jak přetížit
> reprezentaci __str__ v queryset. Konkrétně, mám forms.ModelForm ve kterém
> mám i pole cizí klíč. Konkrétně pak tento cizí klíč omezuji:
>
> *form.fields["coursedate"].queryset =
> CourseDate.objects.filter(id__in=seznam).order_by('date_start’)*
>
> Pokud výsledek této filtrace pustím přímo do generovaného formuláře, pak
> jako výběr možností se nabídne __str__ z modelu CourseDate. Jenže já bych
> potřeboval, pro toto konkrétní použití, přejmenovat jednotlivé objekty, aby
> ve výběru vypadaly lépe než naše interní pojmenování. Ale nějak to nemohu
> vyGooglovat ani přes debugger se tomu ne a ne dostat na kobylku. Poradíte
> někdo?
>
> Díky předem, Standa
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> 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 django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAMD1ck8UuLs7M%3DShPD9wpYsDspEBRYza8vEsN%3D5PYWYWjxxmVQ%40mail.gmail.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
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 django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAKtEf95iPLYMy7pPfWEYWGio3c-10iX%2BWfGvOnmMtvszvUyAag%40mail.gmail.com.

Re: [django-cs] Re: Django admin too danger for integrity

[Pavel Cisar]

@staren...@gmail.com :D komu neni rady, tomu neni pomoci.

pá 19. 2. 2021 v 12:26 odesílatel starenka .  napsal:

> ¯\_(ツ)_/¯
> ---
> In Perl you shoot yourself in the foot, but nobody can understand how you
> did it. Six months later, neither can you. | print 'aknerats'[::-1]
>
>
> On Fri, Feb 19, 2021 at 11:08 AM MirekZv  wrote:
>
>> Díky.
>> Klidně spím, protože si Django nenechávám přerůst přes hlavu. Je to přece
>> jen taková hra.
>>
>> Ty Vaše návrhy si cením, ale zdají se mi mimo (je možné, že jim
>> nerozumím).
>> Já nepotřebuju bránit smazat osobu. Já potřebuju zabránit mazání osoby
>> JEN během vyplňování něčeho naprosto jiného (a navíc křížkem, o kterém
>> vůbec není jasné, že se chystá provést právě toto).
>> Taky nepotřebuju to řešit na úrovni každého Admin nebo každého Model. Ten
>> problém je obecný, všude v adminu. Potřebuju 1 nastavení nebo 2 řádky kódu
>> a zlikvidovat ten nesmysl. Takže patch v templatě formou Javascriptu bude
>> asi nejlepší.
>>
>>
>> Dne pátek 19. února 2021 v 10:44:51 UTC+1 uživatel Ing. Vladimir napsal:
>>
>>> pripadne zakazat vsechno, Mixin pro admin classu :-)
>>>
>>> class NonEditableMixin:
>>> def has_delete_permission(self, request, obj=None):
>>> return False
>>>
>>> def has_change_permission(self, request, obj=None):
>>> return False
>>>
>>> def has_add_permission(self, request, obj=None):
>>> return False
>>>
>>> can_delete = False
>>>
>>> On Fri, Feb 19, 2021 at 10:42 AM starenka .  wrote:
>>>
 A nastav userum spravne prava na modely

 On Fri, Feb 19, 2021, 10:41 starenka .  wrote:

> Nebo si udelej vlastni form na ten inline...
>
> On Fri, Feb 19, 2021, 10:38 Vladimir Linhart 
> wrote:
>
>> nebo
>>
>> readonly_fields
>>
>>
>> On Wed, Feb 17, 2021 at 10:35 PM starenka . 
>> wrote:
>>
>>> Tak si tam dej raw_id a budes klidne spat :)
>>>
>>> On Wed, Feb 17, 2021, 22:15 MirekZv  wrote:
>>>
 PS: ono tedy i ten Edit je příliš nebezpečný. Nějakej Lojza si to
 může otevřít a přepsat Lenku na Martina. Vždycky jsem si myslel, že při
 návrhu ovládání by měly být odlišeny (a tady by to mělo velké 
 opodstatnění)
 plnokrevná editace od opravy překlepu.
 No ale to bych chtěl moc.
 Nicméně asi bych nejradši všude v adminu znepřístupnil tu editaci i
 rušení (přes ForeignKey odkazovaného) záznamu.

 Dokážu to jen tím Javascriptem (což velká věda nebude) nebo to můžu
 někde nastavit?

 Dne středa 17. února 2021 v 22:08:54 UTC+1 uživatel MirekZv napsal:

> Podívejte se na obrázek, jsou tam dva inliny a na začátku každého
> z nich popup s vyplněným jménem Lenka.
>
> Jak se ty popupy liší? jeden má "rušící křížek", druhý ho nemá.
> Jak se liší návrh databáze? Jedno ForeignKey připouští
> null/blank=True, druhé ho nepřipouští.
>
> To null se dá samozřejmě nastavit manipulací popupu pomocí např.
> myši.
>
> Takže nepřekvapuje, že ten křížek dělá něco jiného.
> Zruší osobu Lenka (s celou soustavou CASCADE deleting záznamů).
>
> Když nad tím budeme přemýšlet, nějakou stopu logiky najdeme:
> V obou případech by mohlo být legitimní osobu Lenka zrušit (i když
> proč takovou čistku zrovna při add/edit úplně jiného záznamu?). Ovšem 
> ve
> druhém případě bychom místo té zrušené musely do ForeignKey vybrat 
> nějakou
> jinou osobu (která už ani nemusí v tabulce být, Lenka může být 
> poslední).
>
> Ovšem i když jako programátor tyhle souvislosti nahlédneme, stejně
> je to trochu příliš překombinované. A jak to má pochopit ubohý 
> uživatel?
>
> Neboli se ptám:
> Jak můžu tuhletu nebezpečnou featuru zakázat?
> Dokážu to jedině Javascriptem nebo jsem přehlédnul nějaké
> nastavení?
>
> Díky pokud někdo poradí ...
> [image: broken_integrity.png]
>
 --
 --
 E-mailová skupina djan...@googlegroups.com
 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 django-cs+...@googlegroups.com.
 Chcete-li tuto diskusi zobrazit na webu, navštivte
 https://groups.google.com/d/msgid/django-cs/f3252964-735b-4d30-bc7c-1618d11c3471n%40googlegroups.com
 
 .

>>> --
>>> --
>>> E-mailová skupina djan...@googlegroups.com
>>> Správa: http://groups.google.cz/gr

Re: [django-cs] Dědičnost Django admin šablon

[Pavel Cisar]

Ahoj,
nemuzu si pomoct, ale pripada mi, ze jde spis o nepochopeni podstaty django
admina. Je to skvely nastroj pro nahlizeni do struktury dat a dava moznost
urcitych modifikaci, ale primarne pro vnitrni potrebu.
V dokumentaci v podstate pisou, ze pokud chce clovek neco vic a nevejde se
danych mantinelu, je nacase si napsat vlastni interface a s tim musim
rozhodne souhlasit.
Pokud clovek vyslovene nechce psat neco vlastniho a rad by zmenit vzhled
nebo mel vice moznosti, tak bych ho odkazal na projekty jako:
https://github.com/django-admin-tools/django-admin-tools
https://djangosuit.com/



pá 12. 2. 2021 v 16:42 odesílatel MirekZv  napsal:

> Honza zatím mlčí, odpovím si sám.
> Samozřejmě, že admin/app_list.html se volá na 2 místech.
> Jedno místo popisuje Honza - to je "vhodné k přetěžování".
> Podruhé v nav_sidebar.html, tam opět žádný blok není, neboli další
> šablona, která "není určena k přetěžování".
> Ostatně, kdykoli když slyším slovo "přetěžování", tak už je mi jasné, že
> je něco špatně.
> Takže závěr: Django je jako vždy geniální, já jsem zase ten blbec, co ho
> chce použít k něčemu, k čemu není určeno.
> (sorry za tu mírnou jedovatost, já to tak nemyslím, jen toho mám trochu
> plné zuby)
> Dne středa 10. února 2021 v 18:45:24 UTC+1 uživatel MirekZv napsal:
>
>> PS:
>> Potíž je, že tím předchozím postupem nejen nelze i18n/trans, ale nelze
>> ani vsadit do html jakýkoli string, který bych si připravil předem.
>> Leda můžu v template/base.py místo `raise self.error(token, '%r must be
>> the first tag in the template.' % node,)` dát `pass`,
>> aby Django neprovádělo své přechytralé kontraproduktivní kontroly.
>> Jenže to už je zase patchování Djanga.
>> Ach jo, zlatej Cheetah.
>>
>> Dne středa 10. února 2021 v 18:15:18 UTC+1 uživatel MirekZv napsal:
>>
>>> Mezitím mám jedno řešení.
>>> Dokumentace Djanga je "doslovně" pravdivá: If you use {% extends %} in a
>>> template, it must be the first template tag in that template.
>>> To skutečně znamená, že extends může předcházet (nikoli následovat) html
>>> kód.
>>> To by mi celkem vyhovovalo. Jediné, co mě štve je, že nemůžu použít
>>> nejen {% include ... %}, ale ani i18n/trans :(
>>> Příklad viz obrázky.[image: rap1.png][image: rap2.png]
>>>
>>> Dne středa 10. února 2021 v 18:10:44 UTC+1 uživatel MirekZv napsal:
>>>
 Možná jsem Tě přesně nepochopil.
 Já umím extendovat admin/app_list.html, jenže je mi to k..h..u, protože
 ta v sobě nemá žádný {% block  %} - takže proč ji extendovat?
 Ale možná jsi myslel includovat. To by dávalo smysl.

 A pak taky nevím, jestli to, co píšeš, řeší, aby moje přidané položky
 byly všude: 1) Na hlavní stránce admina, 2) Na stránkách aplikací, 3) V
 sidebar menu během editace.



 Dne středa 10. února 2021 v 17:29:32 UTC+1 uživatel honza...@gmail.com
 napsal:

> app_list.html neni urcena k pretezovani, proto na to neni zarizena.
> Nejjednodussi cesta je:
>
> nastav si custom sablonu na index_template (0). Ve sablone (ktera se
> nebude jmenovat admin/index.html) extenduj index.html a prepis {% block
> content %} kde misto admin/app_list.html naimportujes jinou sablonu, ktera
> byde extendovat admin/app_list.html
>
>
> 0 -
> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.index_template
>
> Honza Král
> E-Mail: honza...@gmail.com
> Phone:  +420 606 678585 <+420%20606%20678%20585>
>
>
> On Wed, Feb 10, 2021 at 5:22 PM MirekZv  wrote:
>
>> Django mi zas dává do těla.
>>
>> Snažím se přidat menu do Django admina.
>> Ačkoli lze najít plno návodů, zdá se mi, že všechno jsou hrozné hacky
>> a přestávají fungovat s nejbližší novější verzí Djanga.
>>
>> Takže by se mi zdálo, že nejbezpečnější by bylo,
>> přidat si svoje vlastní menu položky před to, co generuje šablona
>> admin/app_list.html.
>>
>> Ta totiž generuje seznam aplikací (skupiny menu) a modelů v nich
>> (položky skupin).
>> Tak bych si tam předhodil jednu skupinu se svými odkazy.
>> A fungovalo by to ve všech scénářích, kde se to volá, ať už je to
>> hlavní obsah stránky, nebo to postranní menu (bavím se o Dj 3.1).
>>
>> JENŽE:
>>
>> Když předřadím svoji aplikaci před django.contrib.admin, udělám v ní
>> také admin/app_list.html, tak běží ten můj přednostně a pokud je v něm {%
>> extends 'admin/app_list.html' %}, tak volá následně tu originál 
>> djangovou a
>> nahrazuje v ní bloky , které předefinuji.
>>
>> To funguje a je to snad i popsáno v dokumentaci.
>> Jenže v té originál nejsou žádné bloky. Jsou líní to aspoň jedním
>> blokem owrapovat,.aby šlo předchozí použít.
>>
>> Ale když místo toho dám {% include 'admin/app_list.html' %},
>> tak nejde na tu djangovou originální, ale volá dokola stále tu moji
>> (nekonečná rekurze).
>>
>> Je nějaká možnost jak mít svoji te