[django-cs] Formulár s našeptáváním a předvyplněním údajů

[Stanislav Vasko]

Zdravím,

potřeboval bych poradit, nebo nakopnout na správný směr, jak řešit následující 
problém. Mám aplikaci, která obsahuje data o produktech, vše v modelu Product. 
Z toho potřebuji vytvořit nabídku pro klienta. Ta se skládá z košilky běžných 
prvků jako email, telefon apod., ale zároveň do nabídky potřebuji “nalinkovat” 
nabídnuté produkty. Uvažuji, že udělám formulář pro model Nabídka a pak jako 
formset/formfactory model Nabídka_produkty, kam si poznamenám nabídnuté 
produkty s příslušnou slevou (procenta/fixní cena). Ale, jelikož moc 
nekamarádím s JS (používám ho jen když opravdu musím) a Django mě vždy překvapí 
na co vše má jednoduché a praktické udělátko, jdu se poradit. Nepotřebuji 
řešení, spíše určit smět. Celé mi to “komplikuje” to našeptávání a dynamické 
přidávání/ubírání řádků s produkty, jinak bych šel do formfactory a mám za 
chvíli hotovo.

Co jsem zatím “vymyslel”: napsat si našeptávač pro hledání jako async dotazy do 
Product. Tím by se pak dalo přefiltrovat nějaké pole s nabídkou ID produktů. 
Když si pak uživatel vybere, tak nějakým tlačítkem přidat produkt do formuláře 
pro nabídku produktů (asi nějaký JS, který zase async koukne do Product a 
natáhne data jako název či cena). Při odeslání formuláře si uložím formulář 
Nabídky a následně si z POST vytáhnu i data o produktech a podle potřeby si je 
zpracuji. Jen to asi bude víc práce v JS než v Django.

Co vy na to? Nebo máte tip na nějaký postup/funkci v Django, která se hodí? 
Osobně jsem dost nerad, když musím míchat JS a Django. Je otázkou, zda na toto 
není už správné vystavit modely Product a Nabídka, a přes Rest API použít 
nějaký JS framework jako ucelené řešení. Ale to je pro me až poslední volba.

Díky a hezký večer, 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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/026dd10d-8f45-4260-b854-03dcd10cc809%40Spark.

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

[Stanislav Vasko]

Řeším něco podobného a vlastně jsem to dodnes nevyřešil. Ale abych si to 
zjednodušil, mám vlastně 1 projekt, z něj linkuji klíčové adresáře do 
podprojektů a ty pak běží samostatně. Takže soubory, jádro, aplikace apod. 
existuje jen jednou a každý projekt má vlastní DB, vlastní konfig a třeba 
vlastní images/client kvůli logu apod. drobnostem.

To co popisuješ jsem také promýšlel, ale asi bych se uvýjimkoval a neustále 
myslet na to co kdo má jiného, to bych se zbláznil. Takže až dojde na odbočky, 
asi si udělám přepínače v settings a ty budu číst v nových verzí aplikace a zda 
to bude přepínač ad klient či verze, to ukáže čas. Osobně se ale domnívám, že 
to také není ideální, ale dostatečně jednoduché a tudíž udržitelné. Snad :)

Měj se, Standa
On 7. 11. 2021 12:46 +0100, Vladimír Macek , wrote:
> 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/7d553283-8054-494b-b26e-d83521bad33e%40Spark.

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

[Stanislav Vasko]

Díky oběma. Už mi to fachá a pro přehlednost jsem zvolil první řešení,
protože to mám přímo u formuláře a v budoucnu budu vědět do čeho případně
sáhnout.

Pěkný den, Standa

On 11 April 2021 at 7:50:57, Radim Novotny (novotny.ra...@gmail.com) wrote:


Dá se využít i metoda label_from_instance v ModelChoiceField
https://docs.djangoproject.com/en/3.1/ref/forms/fields/#django.forms.ModelChoiceField.iterator

Stačí jednoduchý subclass ModelChoiceField jak je uvedeno v příkladu v
dokumentaci.

-- 
Radim



On Sat, Apr 10, 2021 at 10:29 PM Pavel Cisar  wrote:

> 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 <http://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 <
> stanislav.va...@gmail.com> 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
>> <https://groups.google.com/d/msgid/django-cs/CAMD1ck8UuLs7M%3DShPD9wpYsDspEBRYza8vEsN%3D5PYWYWjxxmVQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> --
> 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/CAKtEf95iPLYMy7pPfWEYWGio3c-10iX%2BWfGvOnmMtvszvUyAag%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-cs/CAKtEf95iPLYMy7pPfWEYWGio3c-10iX%2BWfGvOnmMtvszvUyAag%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
-- 
-- 
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/CADDKcst1zCVy8dReVrRFht56hPGErqkZTYwkopP3E8ZEPXxpDw%40mail.gmail.com
<https://groups.google.com/d/msgid/django-cs/CADDKcst1zCVy8dReVrRFht56hPGErqkZTYwkopP3E8ZEPXxpDw%40mail.gmail.com?utm_medium=email_source=footer>
.

-- 
-- 
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/CAMD1ck-yT5Q39cqcdrwJzCJSQ07wpu837ctMApnM7hkXQn3yYw%40mail.gmail.com.

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

[Stanislav Vasko]

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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAMD1ck8UuLs7M%3DShPD9wpYsDspEBRYza8vEsN%3D5PYWYWjxxmVQ%40mail.gmail.com.

[django-cs] Django - nativní aplikace pro OSX/Windows

[Stanislav Vasko]

Zdravím,

chtěl bych se zeptat, zda někdo zkoušel vytvořit aplikaci pro OSX/Win10 s 
nativním vzhledem v jazyce Python, ideálně s využitím frameworku Django (nebo s 
Django aplikací komunikující). Existuje nějaká obvyklá cesta pro vytvoření 
nativní aplikace v Pythonu pro správu Django aplikace? Našel jsem nějaké cesty 
k mobilní aplikaci (i možnost webu předstírající aplikaci), ale nedaří se mi 
najít nic podobného pro desktop. Knihovny, které jsem našel, vypadají jak z 
doby Win98. Nepotřebuji aby výsledný kód byl nějak extra optimalizovaný, ale 
aplikace musí vypadat jako nativní. Budu rád za každé nasměrování na nějaké 
moderní a funkční řešení, pokud Python/Django takové umožňuje.

Díky a hezký víkend, 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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/3ee04a39-e02d-4048-93e0-671bd253f956%40Spark.

Re: [django-cs] Re: Jak co nejlépe a obecně na popupy?

[Stanislav Vasko]

Já bych nebyl až tak kritický. Osobně jsem se tam několikrát inspiroval a 
přestože některé věci už řeším jinak, dalo mi to možnost mít alespoň nějaké 
řešení, většinou opravdu simple. Jsem rád za každé srozumitelné návody, zvláště 
proto, že v češtině prakticky nic uceleného neexistuje. Sice mluvím anglicky 
plynule, ale učit se nové věci je pro mne příjemnější v češtině. Takto přímé a 
srozumitelné návody se velice snadno a dobře konzumují a vysloveně nesmysly 
jsem tam snad nikdy neviděl.

Btw: mátě někdo tip na podobnou stránku, jen pro vyšší level? Většinou na 
potřebné téma vždy najdu velice pěkné články, ale nic uceleného a mnohahodinová 
videa na YT mně nikdy nebrala.

Standa
On 2. 3. 2021 11:08 +0100, MirekZv , wrote:
> Nemám na to moc času, zatím mně z toho ale vychází, že, jakkoli mám rád ty 
> stránky simpleisbetterthancomplex, tak tady to je asi ztráta času a krok 
> nesprávným směrem.
> A že správně bude použít django-autocomplete-light, který nejspíš přesně 
> všechno toto řeší.
>
> > Dne pátek 26. února 2021 v 10:25:08 UTC+1 uživatel MirekZv napsal:
> > > Mám ne moc minimalistické, ale pro reálné projekty nutné požadavky na 
> > > popupy (select+options) ve formulářích:
> > > 1. ajaxem získávané options (mimo admin i v něm) - všude a vždy, i když 
> > > kdyby to umělo automaticky vypnout, když je v modelu méně než např. 100 
> > > položek, nevadilo by,
> > > 2. dynamický filtr pro options, zejména když jsou relačně závislé popupy 
> > > (opět mimo admin i v adminu, včetně inlinů); příklad: country & city: jen 
> > > cities z vybrané country mají být na výběr.
> > >
> > > Implementoval jsem toto
> > > https://simpleisbetterthancomplex.com/tutorial/2018/01/29/how-to-implement-dependent-or-chained-dropdown-list-with-django.html
> > > včetně funkcionality (2) v inlinech a dokážu to zprovoznit.
> > >
> > > Ale je zatím dost individuální práce pro každý případ, lepší by bylo něco 
> > > generického.
> > > A neřeší to ten ajax.
> > >
> > > Je nějaká rozumná cesta, jak dosáhnout (1)+(2) všude v aplikaci?
> > > Které packages přidat do projektu? django-autocomplete-light? a ještě 
> > > něco?
> > >
> > > Díky...
> > > PS: samozřejmě, když jsem šel na Django, tak jsem se domníval, že tam jdu 
> > > proto, že takovéto věci dělá out-of-the-box. Ach ta moje naivita.
> > >
> > > Best regards,
> > > Mirek
> --
> --
> 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/e080bd5f-e7a7-49f3-84cd-3afe0804a958n%40googlegroups.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/10976f3f-2726-4b38-b890-16c34f6d3a34%40Spark.

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[Stanislav Vasko]

Díky všem za reakci. Osobně jsem se na produkci také nikdy nevracel, ale
tak ještě to důležité:

DB spravujete přes DB aplikaci, extra, nebo jsou v Django na to příkazy,
jako jsem uváděl níže?

Standa


On 26 February 2021 at 1:24:18, starenka . (staren...@gmail.com) wrote:

Messa: session muze mit x backendu, samorejme se cachuje atd. bylo mi jasny
uz pri psani, ze budes kejhat :)

Slo o zdurazneni pointu, ze sqlite imo na produkci neceho min nez toy
projektu nema co delat...

On Fri, Feb 26, 2021, 01:11 Petr Messner  wrote:

> pá 26. 2. 2021 v 0:51 odesílatel starenka .  napsal:
>
>> Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je mi
>> znamo) nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni
>> jeden worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve
>> fronte (cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i
>> "mimo tvuj kod" (napr. session), neni to asi obecne idealni reseni pro
>> vytizenejsi appky.
>>
>
>
> Je to v praxi (u menších aplikací) opravdu problém? I ve WAL módu?
> https://sqlite.org/wal.html
>
> Jestli i obyčejný read-only přístup do session znamená nějaký zápis do db,
> tak to možná není ideální a dá se to řešit několika způsoby. Ale dobrý
> point, někdy je třeba na toto myslet.
>
> Petr M.
>
>>
> --
> --
> 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/CAK9Q5BTYd-eumm-7pjVWFctwz9Rrpab0LpfMMBuwiophq-2-UA%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 tuto diskusi zobrazit na webu, navštivte
https://groups.google.com/d/msgid/django-cs/CA%2B7MNVpFKOgPSqyj1VbndGeFmUaXT67xt6QCfT0aOgfWHDuqfw%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/CAMD1ck8UOOnkpzNQy%2BKiwniegg4-%3DbHBJhgQofXCjaOhwPYgtQ%40mail.gmail.com.

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[Stanislav Vasko]

Možná užíváním SQlite mám problémy o kterých ani nevím, ale mám ji na
webech u miniklientů s návštěvností třeba 30-100 lidí za den apod. Na
lokále, kde verzuji, nemám v DB prakticky nic, jde prostě jen o to pohodlí,
že když něco udělám blbě (teď jsem třeba našel ve starším projektu chybu
práce Django s migracemi), tak prostě hodim Discard na migrace, DB a jsem
“čistej”. Prostě pohodlí, nic neriskuji, alespoň a těchto mini věcech jsem
nikdy nenarazil na chybu.

Ale zpět k mému dotazu: jak tedy obecně pracujete s kódem vs DB? Jak se
vracíte v čase na DB na vývoji? A máte stejné migrace na ostrém i na
vývojovém prostředí? Opravdu umí Django tím migrate a názvem migrace “samo
a automaticky” změnit DB na stav v jakém skutečně byla před aplikací
následných migrací?

Díky.


On 26 February 2021 at 0:51:48, starenka . (staren...@gmail.com) wrote:

Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je mi znamo)
nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni jeden
worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve fronte
(cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i "mimo
tvuj kod" (napr. session), neni to asi obecne idealni reseni pro
vytizenejsi appky.

On Fri, Feb 26, 2021, 00:34 Honza Král  wrote:

> Ahoj,
>
> muzu se hlavne zeptat k cemu tu databazi pouzivas? Podle tveho workflow
> (SQLite soubor v gitu) hadam, ze jde pomerne o nestandardni pouziti atak by
> me to zajimalo.
>
> Typicky totiz data vznikaji na produkci a neni treba, ani zadouci, nejak
> zajistovat "aby byla zajištěna úzká vazba mezi verzí/stavem DB a projektem"
> na ramec klasickych migraci schematu, coz django resi pomerne dobre.
>
> On Fri, Feb 26, 2021 at 12:20 AM Stanislav Vasko <
> stanislav.va...@gmail.com> wrote:
>
>> Měl bych tu dotaz z kategorie začínáme s Django, ale prostě nemohu najít
>> (možná to hledám/řeším moc složitě) jednoduché řešení. Potřeboval bych na
>> pár projektech přejít na PostgreSQL, ale docela se bojím, resp. neumím si
>> představit automatické zálohování a hlavně případnou práci na DB, kdyby se
>> něco vysypalo. Zatím tyto “dospělé” SQL moc nevyužívám, protože práce s
>> nimi je pro mne většinou komplikací.
>>
>> Už několik let, až na pár projektů, používám SQLite DB a jsem vlastně
>> spokojen. Jasně, něco člověk musí oželet, ale mít DB jako soubor přímo v
>> projektu má pro mne, a hlavně menší projekty, krásu a přináší pohodlí.
>> Například si DB hodím do GITu s projektem a případný problém vyřeším
>> vratkou k vybranému bodu, ostrý projekt jednoduše zkopíruju a pustím
>> lokálně, zkopíruji projekt a mám novou microsite ready na test atd. A tady
>> bych rád věděl jednu zásadní věc:
>>
>> Jak takovéto operace provádět na běžném (My/Postgre)SQL podvozku, aniž by
>> to neznamenalo neustálé extra práci s DB a hlavně aby byla zajištěna úzká
>> vazba mezi verzí/stavem DB a projektem? Už jen vytvoření zálohy před
>> instalací nové verze znamená se min. extra postarat o DB a extra soubory a
>> to si někde společně uložit. Obnovení, přenos apod., vždy extra práce.
>> Lokálně vystavit projekt znamená někde DB export, lokálně import, upravit v
>> settings… prostě takové, šišaté  a když jsou větší data, tak pak místo
>> přenosu řeším limity na hostingu a další závilosti. Ale i přesto bych
>> potřeboval PostgreSQL nebo alespoň MySQL pro projekty, které už dorostly.
>>
>> A co jsem zatím kdykoliv hledal a studoval, našel jsem krásné a elegantní
>> řešení a tak si říkám, že i na toto musí Django něco nabízet. Jen to nějak
>> v záplavě jiného, či špatných dotazů, nemohu najít. Kdysi jsem migroval z
>> SQlite na PostgreSQL jednu rychle rostoucí aplikaci, a co si pamatuji, tak
>> to šlo poměrně snadno jen spouhým *./manage.py dumpdata* a *./manage.py
>> loaddata*, ale šlo o poměrně malý projekt s minimem závislostí. Dá se
>> takto snadno řešit vše a lze tomu věřit, opravdu se data obnoví? Nebo na
>> toto má Django jiná udělátka?
>>
>> Budu rád i za pouhé nasměrování, co mi uniká a co si mám donačíst, stačí
>> link do dokumentace, už se pak chytím. Díky.
>>
>>
>> --
>> --
>> 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/CAMD1ck8socFgW6z2pjDRWfgxJ8BejPzoaXQU%3DXesv06FACnsUQ%40mail.gmail.com
>> <https://group

[django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[Stanislav Vasko]

Měl bych tu dotaz z kategorie začínáme s Django, ale prostě nemohu najít
(možná to hledám/řeším moc složitě) jednoduché řešení. Potřeboval bych na
pár projektech přejít na PostgreSQL, ale docela se bojím, resp. neumím si
představit automatické zálohování a hlavně případnou práci na DB, kdyby se
něco vysypalo. Zatím tyto “dospělé” SQL moc nevyužívám, protože práce s
nimi je pro mne většinou komplikací.

Už několik let, až na pár projektů, používám SQLite DB a jsem vlastně
spokojen. Jasně, něco člověk musí oželet, ale mít DB jako soubor přímo v
projektu má pro mne, a hlavně menší projekty, krásu a přináší pohodlí.
Například si DB hodím do GITu s projektem a případný problém vyřeším
vratkou k vybranému bodu, ostrý projekt jednoduše zkopíruju a pustím
lokálně, zkopíruji projekt a mám novou microsite ready na test atd. A tady
bych rád věděl jednu zásadní věc:

Jak takovéto operace provádět na běžném (My/Postgre)SQL podvozku, aniž by
to neznamenalo neustálé extra práci s DB a hlavně aby byla zajištěna úzká
vazba mezi verzí/stavem DB a projektem? Už jen vytvoření zálohy před
instalací nové verze znamená se min. extra postarat o DB a extra soubory a
to si někde společně uložit. Obnovení, přenos apod., vždy extra práce.
Lokálně vystavit projekt znamená někde DB export, lokálně import, upravit v
settings… prostě takové, šišaté  a když jsou větší data, tak pak místo
přenosu řeším limity na hostingu a další závilosti. Ale i přesto bych
potřeboval PostgreSQL nebo alespoň MySQL pro projekty, které už dorostly.

A co jsem zatím kdykoliv hledal a studoval, našel jsem krásné a elegantní
řešení a tak si říkám, že i na toto musí Django něco nabízet. Jen to nějak
v záplavě jiného, či špatných dotazů, nemohu najít. Kdysi jsem migroval z
SQlite na PostgreSQL jednu rychle rostoucí aplikaci, a co si pamatuji, tak
to šlo poměrně snadno jen spouhým *./manage.py dumpdata* a *./manage.py
loaddata*, ale šlo o poměrně malý projekt s minimem závislostí. Dá se takto
snadno řešit vše a lze tomu věřit, opravdu se data obnoví? Nebo na toto má
Django jiná udělátka?

Budu rád i za pouhé nasměrování, co mi uniká a co si mám donačíst, stačí
link do dokumentace, už se pak chytím. Díky.

-- 
-- 
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/CAMD1ck8socFgW6z2pjDRWfgxJ8BejPzoaXQU%3DXesv06FACnsUQ%40mail.gmail.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Stanislav Vasko]

@jnwltr nějaký přímý odkaz na nějaké demo, ať se inspiruji? Zní mi to totiž
přesně jako řešení na tu “nudnou práci uprostřed”.

@Honza to nevypadá zle, kéž by to mělo už masovější použití

btw: možná to nic neřeší, ale není krokem “do mezi” to async řešení v
Django 3.1, už to někdo někde nasadil a podařilo se tím ušetřit nějaký ten
čas? Nebo je to jen lepší AJAX?

SV


On 23 February 2021 at 10:09:06, Honza Javorek (m...@honzajavorek.cz) wrote:

Uvažoval nebo použil někdo
https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga
generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad tím?
Existuje to dlouho a Basecamp (37signals) to používá odjakživa, teď tomu
dali akorát webovku a název, protože je štval nedostatek protiváhy k
termínům jako SPA a Jamstack.

Honza


On Tue 23. 2. 2021 at 10:02, Jan Walter  wrote:

> My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django REST
> Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj naším
> (opensource) generátorem vygenerujeme celou komunikační vrstvu na FE, čili
> tímhle netrávíme ani minutu času, v běžných scénářích je vše krásné a
> otypované (jeden model).
>
> Určitě takovou věc lze najít/mít i pro react/vue.
>
> On Tue, 23 Feb 2021, 09:41 Stanislav Vasko, 
> wrote:
>
>> Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
>> Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
>> kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
>> Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
>> vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
>> je proti Django response/request časově úplně jinde a u menších aplikací se
>> mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
>> srozumitelně :)
>>
>> SV
>>
>>
>> On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
>> wrote:
>>
>> Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe
>> bronzove delal pomoci https://www.django-rest-framework.org/ - znas?
>>
>>   Jirka
>>
>> On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
>> wrote:
>>
>>> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
>>> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>>>
>>> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
>>> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
>>> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
>>> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
>>> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
>>> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
>>> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
>>> programováním komunikace Django <-> Vue bych strávil více času než s
>>> aplikací samotnou.
>>>
>>> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si
>>> celou integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a
>>> Vue řešit až po přechodu na zcela jiný BE.
>>>
>>> SV
>>>
>>>
>>> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com)
>>> wrote:
>>>
>>> Zdravím,
>>> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů,
>>> ale také to má své výhody:
>>>
>>>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>>>(některé), je třeba řešit server-side-rendering (firebase, ...)
>>>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>>>- většinou je třeba dva lidi/týmy - BE/FE.
>>>- nutnost udržování dokumentace API
>>>- FE frameworky mají životnost jepice - od začátku psaní tohoto
>>>mailu do konce bylo určitě vydáno několik main verzí reactu, angularu, 
>>> npm
>>>a javascriptu...
>>>
>>>
>>>
>>>- znovupoužitelnost BE api je super v tom, že se může připojit jak
>>>web frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>>>strany.
>>>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>>>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>>>- na tvorbu microservis je to velmi výhodný koncept.
>>>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>>>nevěřím)
>>>- front je zpravidla rychlejší, tahá se mé

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Stanislav Vasko]

Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
je proti Django response/request časově úplně jinde a u menších aplikací se
mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
srozumitelně :)

SV


On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
wrote:

Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe bronzove
delal pomoci https://www.django-rest-framework.org/ - znas?

  Jirka

On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
wrote:

> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>
> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
> programováním komunikace Django <-> Vue bych strávil více času než s
> aplikací samotnou.
>
> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si celou
> integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a Vue
> řešit až po přechodu na zcela jiný BE.
>
> SV
>
>
> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:
>
> Zdravím,
> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
> také to má své výhody:
>
>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>(některé), je třeba řešit server-side-rendering (firebase, ...)
>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>- většinou je třeba dva lidi/týmy - BE/FE.
>- nutnost udržování dokumentace API
>- FE frameworky mají životnost jepice - od začátku psaní tohoto mailu
>do konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
>javascriptu...
>
>
>
>- znovupoužitelnost BE api je super v tom, že se může připojit jak web
>frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>strany.
>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>- na tvorbu microservis je to velmi výhodný koncept.
>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>nevěřím)
>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>prohlížeči.
>
>
> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>
> MK
>
> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
> stanislav.va...@gmail.com> napsal:
>
>> Zdravím,
>>
>> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
>> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
>> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
>> nějak k němu inklinuji, tak snad to není špatná volba.
>>
>> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
>> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
>> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
>> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
>> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
>> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
>> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
>> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>>
>> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
>> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
>> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
>> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
>> vytvářím REST API konektory a ve Vue je napojuji.
>>
>> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
>> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
>> nezávisle), bych v JS backendu vyřešil e

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Stanislav Vasko]

Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.

Co mi žene krev do očí je to API. Ano, REST API v Django je sranda, zvláště
pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def serve() si
udělám s daty cokoliv, hlavně pak snadno pořídím kontextové informace a
ještě v šabloně se dá případně leccos, když je člověk pohodlný. Ale co s
Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na druhé
straně rozbalovat? Na velkých projektech s oddělením na BE a FE pohoda a
dokonce i výhoda, ale u malých projektů zcela mimo, protože s programováním
komunikace Django <-> Vue bych strávil více času než s aplikací samotnou.

Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si celou
integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a Vue
řešit až po přechodu na zcela jiný BE.

SV


On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:

Zdravím,
ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů, ale
také to má své výhody:

   - čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
   (některé), je třeba řešit server-side-rendering (firebase, ...)
   - ano, je třeba objevovat kolo hlavně z pohledu routování url adres
   - většinou je třeba dva lidi/týmy - BE/FE.
   - nutnost udržování dokumentace API
   - FE frameworky mají životnost jepice - od začátku psaní tohoto mailu do
   konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
   javascriptu...



   - znovupoužitelnost BE api je super v tom, že se může připojit jak web
   frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
   strany.
   - člověk se na BE nemusí starat o html/css a řeší jen databázi,
   performance, rest/graphql ... (vyhovuje teda alespoň mě)
   - na tvorbu microservis je to velmi výhodný koncept.
   - ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
   nevěřím)
   - front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
   dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
   prohlížeči.


Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.

MK

po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko 
napsal:

> Zdravím,
>
> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
> nějak k němu inklinuji, tak snad to není špatná volba.
>
> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
> knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
> vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>
> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
> vytvářím REST API konektory a ve Vue je napojuji.
>
> Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
> napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
> nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
> že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.
>
> Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
> Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
> nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
> už, tak pořádně.
>
> Hezký večer, 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/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.googl

[django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Stanislav Vasko]

Zdravím,

stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
nějak k němu inklinuji, tak snad to není špatná volba.

Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou tu
knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace: 1.
vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
naopak všechno “to krásné” z Django je významně zredukováno na něco málo
víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
vystavení 2 nezávislých aplikací, které spolu úzce souvisí.

Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se to
takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
vytvářím REST API konektory a ve Vue je napojuji.

Neznám JS backendy, ale možná, co já otrocky vytvářím v Django a ručně
napojuji na Vue (a při změně musím ošetřit/opravit na dvou místech
nezávisle), bych v JS backendu vyřešil elegantněji? Chci se prostě ujistit,
že takto to dělají ostatní a neuniká mi nějaké elegantnější řešení.

Díky za tip na lepší řešení či ujištění, že takto je to opravdu správně.
Uvítám případně i odkazy na tutoriály či knihy, které Vám s Vue pomohly
nebo je můžete doporučit. Bez JS to prostě u mě dál již nepůjde a tak když
už, tak pořádně.

Hezký večer, 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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAMD1ck_Bg88W-baXGROKms2LDKyrJOM6E1Kf6dOmcSiQPF7CMQ%40mail.gmail.com.

Re: [django-cs] emmett

[Stanislav Vasko]

Django, Masonite a vše další bude tak dobré a efektivní, jak dobře to budeš
umět. Když se podívám 3 roky zpět, musím se smát, kolik času jsem promrhal
a na druhou stranu jak jsem si věci komplikoval. Prostě výtečně knížky jako
Two scoops of Django (mimochodem doporučuji!), PyCharm či YT tutoriály mi
začaly dávat smysl, a dokázal jsem pochopit celý obsah, až jsem měl něco
odprogramováno. Prostě programuj, ono to přijde…

Jinak očima programátora (pokud už se tak mohu označit), se mi zdá, že čím
více toho umím, tím snazší by bylo přejít na cokoliv jiného. Když jsem
nedávno koukal do Flask, bez větších problémů jsem se zorientoval. Postupy
jak co řešit mi dávaly zásadně lepší logiku než když jsem kdysi, se
základní znalostí Python 3, koukal různé tutoriál a videa typu “how to do
in …..” nebo zcela ztracený čas u “django vs flask vs ….”. Myslím, že vůbec
nemá cenu řešit Django vs jiné, dokonce nemá ani větší význam řešit Django
vs Ruby vs Laravel atd. Logika a východiska jsou velice podobná

Ano, je tu stále otázka, zda JS komplet, nebo kde si dát hranici mezi JS a
Django. Tak hurá na videa “Django REST API and Vue”. Všichni ostatní mohou
trávit čas u “JS vs Django vs Laravel” a “what to learn in 2021” :)

Standa

On 17 February 2021 at 14:04:29, MirekZv (mirek.zvol...@gmail.com) wrote:

Mně ten dnešní JavaScript připadá už docela hezký, skoro jako Python. Teda
kdyby ho někdo zvládl sám a začal si v tom psát, pokud pro někoho, tak asi
spadne do legacy projektu a to nikomu nepřeju.
K Vue jsem si poznamenal toto video, bylo by fajn, kdyby někdo znalejší na
to mrknul a řekl, jestli mu to přijde jako správný směr.
https://www.youtube.com/watch?v=3eTtVY7duJk
Kromě emmett jsem objevil další pokus o fullstack v Pythonu: masonite. Ale
dokud se něco z toho nestane trochu mainstream, nemá smysl po tom koukat. A
já nechci od Djanga zdrhat. Jenom bych rád celou tvorbu webu zvládal
efektivně vč. deployment a javascriptu i v 1 člověku a nejsem si jistý,
jestli Django byla nejlepší volba. No ale už jsem ji udělal. A myslím, že
třeba po 2 letech učení a 2 letech budování nějaké vlastní infrastruktury
by se třeba uspět dalo.

Dne středa 17. února 2021 v 10:04:50 UTC+1 uživatel stanisl...@gmail.com
napsal:

> Tak toto naprosto podepisuji. Před pár lety jsem se vrátil k programování
> a strávil neskutečné množství času hledáním svatého grálu, volbou
> jazyka/frameworku. Hodně jsem váhal mezi nějakým JS a Python frameworkem.
> Nakonec vyhrál Python pro svoji obecnou použitelnost, ale s nabývajícími
> zkušenostmi jsem zjistil, že JS není špatná volba, resp. že by mi fungovalo
> obojí. Nicméně JS, pohledově a zápisem, mi vůbec nevyhovuje a nesedí.
> Dodnes jsem si k němu nenašel cestu, ale musím, klienti to vyžadují.
>
> Co se týče frameworků pro Python, tak vyhrálo Django. Dlouho jsem měl
> úmysly si adoptovat něco “menšího a obratnějšího” na malé projekty,
> microsite, prezentaci dat apod. Nakonec jsem to zavrhl a udělal jsem jen
> dobře. Dneska i na microsite jde rovnou Django jako podvozek. Typicky
> projekt 2 měsíce zpět: pár skriptů pro úpravu XML mezi dodavatelem a
> odběratelem. Vše hozeno jako “robůtci” do jednotlivých Views, adresy do
> Urls a bylo hotovo. Ale za 2 týdny najednou potřebovali překládat
> produktová data s výpočtem nějakých dalších hodnot a držet některá data v
> čase: další App + Model + Views + Urls a do Crontab pak volání pár Urls.
> Pak další: simple administrace, výpis produktů, čistě funkčně,
> nepotřebovali žádnou krásu. Nakonec zaheslovat přístup. Pohoda, “vždy
> připraven", vše hned a bez problémů. A pro mne nejzásadnější výhoda: vše
> systematicky. Dneska již mohu říct, že se vracím k projektům co jsem 2 roky
> “neviděl”. Vím kam sáhnout, jak a co řešit nebo jak projekt “the right way”
> doplnit/upravit. U starších projektů, a to nejsem žádný bastlíř a patlal,
> buď vzpomínám jakou cestu/řešení jsem zrovna zvolil a nebo hledám v
> dokumentaci (i proto, že už danou věc nepoužívám). Prostě, Django chleba na
> severu nežere, nepřekáží, ale když je třeba, pomůže.
>
> A co se týče JS, tady budu rád za každou radu, zkušenost co píšete. JS se
> mi vizuálně nelíbí a navíc skripty ve stránce nemám rád. Je to hlavně
> proto, že Request->Response cyklus je jasný, mám vše pod kontrolou. Jít
> dopisovat v JS něco do stránky kde už řádí řada jiných funkcí mi proti tomu
> připadá jak minové pole. Ale uznávám, je to nejspíše jen moje
> neznalost/nezkušenost. Proto hledám cestu jak klientům přinést lepší
> frontend a sobě nezničit zdraví. Zatím to vidím na Vue.js, + REST API. Jen
> mi pak připadá už trochu zvláštní přes View poslat prvotní stav a zbytek
> řešit REST API. Možná nejsem daleko od stavu, kdy Django bude jen backend a
> frontend už převezme Vue (či něco podobného) kompletně. Mimochodem, nějaký
> tip na praktickou či zajímavou knihu/eLearning pro efektivní tvorbu
> Frontendů s JS frameworkem neznáte?
>
> Nějak jsem se rozepsal, budu rád když mi napíšete nějaký tip jak na ten JS
> vyzrát. Každopádně se 

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

[Stanislav Vasko]

Ahoj,

to tak vlastně mám. To přetěžování přes appky per klient zvážím, ale asi až při 
větších změnách, jinak by mohly (do určitého času) stačit výhybky. Ale jdu do 
něčeho takového poprvé, ale tuším, že od určitého počtu klientů a změn budou 
problémy.

Co vidím jako klíčový problém a kdy oddělit je změna v DB. Jak ale oddělí DB, 
už to skoro můžu rozsejat celé :/

Díky moc, jdu to poválet v hlavě, Standa 

> On 12 Sep 2020, at 09:39, Jakub Vysoky  wrote:
> 
> 
> Abychom ti dokazali spravne poradit, museli bychom vedet, jak velike jsou 
> rozdily v tech jednotlivych "instalacich" pro ruzne klienty.
> 
> Za me je urcite "spravne" mit:
> 
> * jednu spolecnou knihovnu v niz je vetsina funkcionality (vetsina django 
> apps)
> * virtualenv per klient
> * v kazdem virtualenvu pro kazdeho klienta jejich vlastni django projekt 
> (cili django settings, INSTALLED_APPS)
> * nejspis i v tom vlastnim projektu jednu django appku, kterou mohu 
> customizovat sablony, pridavat nejakou funkcionalitu, ktera je unikatni pro 
> daneho klienta
> 
> Vsechno bych instaloval pomoci pipu - i kdyz to bude z nekolika vlastnich 
> repositaru - to neni zas takovy problem. A urcite mel minimalne na upgrade 
> nejaky skript, at to volam vzdycky stejne. Ansible je urcite super, ale muze 
> byt pro tebe prekazka na nauceni se.
> 
> Stejne tak mozna v tvem pripade by moje navrhovane oddeleni bylo zbytecne 
> silne. Ale ja bych to videla do budoucna nejspolehlivejsi.
> 
> Drzim palce!
> 
> 
>> On Sat, Sep 12, 2020 at 2:11 AM Vladimír Macek  wrote:
>> Ahoj,
>> 
>> a) jedna z cest na začátku vývoje byla, že bys měl projekt koncipovaný jako 
>> multi-tenant, tzn. databáze a globální objekty (glob. objekty, cache, fajly, 
>> ...) by s izolací klientů počítaly. Pak bys to měl na jednu stranu 
>> jednoduché s údržbou. Bylo by ale neustále nutné hlídat tu izolaci a 
>> udržovat rozdíly ve funkčnostech.
>> 
>> b1) Když by funkčních rozdílů mezi doménami bylo míň, můžeš vyvíjet JEDEN 
>> projekt pro všechny, provozovat pro každého klienta extra instanci, ale z 
>> JEDNOHO branche. Funkční rozdíly mezi doménami by se rešily výhybkami v kódu.
>> 
>> Zdrojáky na serveru můžou být jen jednou, dokonce i virtualenv jen jeden, 
>> jen různé settings, databáze a file storage.
>> 
>> b2) Větší funkční oddělený celek, by se dal uzavřít do apky, kterou by v 
>> INSTALLED_APPS měli jen příslušní klienti. Pozor, stále se z ní dá 
>> importovat. 
>> 
>> c) Silnější varianta je udržovat takovou per-instance apku jako separátně 
>> instalovanou jen do virtualenvu příslušného klienta. Pak by importovatelná 
>> nebyla, ale pro klienty bys již musel udržovat oddělené virtualenvy.
>> 
>> Zde bych jit doporučil nástroj na automatický deployment, například Ansible. 
>> Nedávno jsem ho zavedl do svého toolsetu a je opravdu fajn. Deployneš novou 
>> verzi všem najednou, klidně s customizacemi.
>> 
>> d) Může tě zaujmout ještě další varianta: Společnou část projektu bys 
>> udržoval v hlavním git branchi, třeba 'prod' (jako produkční). A pak bys pro 
>> klienta požadujícího změnu vytvořil branch 'prod-klient1', ve které by 
>> oproti 'prod' byly změny, které tento klient chtěl.
>> 
>> Vývoj a bugfixy společných částí bys pushoval do 'prod' a hned mergnul do 
>> všech 'prod-*' branchů. Abys nezapomněl, můžeš si nastavit různé git hooky 
>> -- jen varovací nebo i blokující, že třeba nepushneš 'prod-*', pokud jsi do 
>> něj zapomněl mergnout 'prod'. 
>> 
>> Chce to jenom větší sebekázeň, ale git je na souběžný vývoj přímo dělaný. 
>> Výhody jsou, že git ti vždycky krásně zobrazí diffy mezi společnou verzí a 
>> klienty i mezi klienty navzájem. U žádného klienta není kód navíc. 
>> Nespolečné commity si navždy ponesou své messages, kde svému budoucímu já 
>> podrobně vysvětlíš, proč existují. To se u výhybek ne vždy daří. Viděl bych 
>> i omezený dosah chyb v 'prod-*' brenčích. Další výhoda mě napada, že když 
>> při mergi do 'prod-*' dojde někde k průniku změn (nechci říkat přímo 
>> kolizi), přiměje tě to k úvaze, jestli dělení funkčností koncipuješ dobře.
>> 
>> Ansible ti opět na jediný příkaz deployne do virtualenvů všech klientů, 
>> každého z příslušného branche gitu.
>> 
>> V každém případě si veď dokumentaci kdy, kdo, chtěl jakou změnu, proč ji 
>> chtěl, jak jsi s ním o úpravě diskutoval. Tvým zájmem je mít rozdíly v kódu 
>> mezi klienty co nejmenší.
>> 
>> Měj se, ať to jde,
>> 
>> Vláďa
>> tel. 608 978 164
>> 
>> 
>>> On 12. 09. 20 0:25, stanisl...@gmail.com wrote:
>>> 
>>> Zdravím,
>>> 
>>> potřeboval bych poradit či navést na best-practice v Django, jak jeden 
>>> projekt nasadit pro více firem, ale tak, abych v čase mohl dělat klientské 
>>> modifikace. Aktuálně jsem vymyslel aplikaci a používají ji 2 moji klienti. 
>>> Django aplikace běží na nGinx a abych mohl obě aplikace aktualizovat 
>>> současně, na serveru jsem nalinkoval společné zdrojové kódy (virtuál 
>>> linkuje společné adresáře/aplikace). Vše běží, protože každá aplikace má 
>>> svou 

[django-cs] Re: Prosba o radu - jsem začátnečník

[Stanislav Vasko]

Na které škole začínají tak ostře, hned založením souboru navíc s 
básničkou? 

On Friday, 10 January 2020 14:49:48 UTC+1, Martin Jašurek wrote:
>
> Prosím o radu: viz níže text První revize. Nechápu, kde mám vytvořit 
> soubor basnicka.txt, v čem vytvořit soubor. Děkuji
>
>  
>
> První revize
>
> Teď si zkus do Gitu něco přidat!
>
> Vytvoř soubor basnicka.txt a napiš do něj nějakou básničku. Měla by mít 
> aspoň pět řádků, ať pak máme s čím pracovat. Pak zkus znovu git status: 
> Git oznámí, že v adresáři je soubor, o kterém ještě „neví“.
>
>
> Děkuji
>
>
> Martin J
>

-- 
-- 
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/487fde33-9934-48e7-9b94-5b26cc212e37%40googlegroups.com.

Re: [django-cs] Volba databáze a její možnosti

[Stanislav Vasko]

Už mi na serveru běhá PSQL. Nevím sice úplně dobře proč, ale funguje a 
dělám testy výkonu. Zatím to vypadá velice slibně a i přes slušnou zátěž DB 
reaguje velice svižně. Zkusím do DB dát 100 mega řádků a uvidíme jak se 
bude tvářit pak. Pokud klienta trochu ukrotím v pohledu na "nutně" 
skladovaná data bych neměl mít větší problém. Teď už jen vyřešit to 
verzování stavu DB proti zdrojáku a jsem spokojen.

Díky všem za navedení. Kdybyste případně ještě měli nějaký dobrý článek jak 
se efektivně poprat s Views resp. jak prakticky si DB donutit automaticky 
tvořit data co potřebuji, budu max. šťastný a udělám si malé vánoce :)

Příjemný večer.

On Friday, 30 November 2018 14:31:59 UTC+1, Messa wrote:
>
> MySQL je super - když si do ní chceš naprogramovat vlastní engine.
>
> Takže asi tak :)
>
> PM
>
>
> pá 30. 11. 2018 v 14:02 odesílatel Jan Walter  > napsal:
>
>> Nevim jak dneska, ale mysql nebyla pred lety dobra (plnohodnotna) relacni 
>> db, postgres je naopak supr uz hodne dlouho. Svyho casu jsem si napr. delal 
>> benchmarky rychlosti beznych r/w operaci pro vetsi stromovy struktury 
>> (postgres, mssql, neo4j) a postgres vychazel v podstate nejlip.
>>
>> Plus indexace json typu pro flexibilitu, jak rika starenka, podle me 
>> robustni (jedno z mnoha, urcite) reseni.
>>
>> Bezny dotaz na par tisic zaznamu z par milionu musi byt za destitky max 
>> malo stovek ms, jak rikaji ostatni.
>>
>> Jinymi slovy postgres rozhodne neni spatna volba.
>>
>> On Fri, 30 Nov 2018, 12:12 Jirka Vejrazka, > > wrote:
>>
>>> Tri miliony radku jsou jen drobne, pokud spravne pouzijes indexy. Mel 
>>> bys byt na zlomcich sekund pro jeden dotaz (a pokud ten dotaz nevraci 
>>> tisice zaznamu)...
>>>
>>>  Jirka
>>>
>>>
>>>
>>> On Fri, 30 Nov 2018 at 10:34, Stanislav Vasko >> > wrote:
>>>
>>>> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z 
>>>> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v 
>>>> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou 
>>>> WHERE 
>>>> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca 
>>>> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji 
>>>> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite 
>>>> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst. 
>>>> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto 
>>>> dobu aplikaci odstavit či házet errory.
>>>>
>>>> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL 
>>>> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat 
>>>> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z 
>>>> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než 
>>>> cokoliv co spáchám já :)
>>>>
>>>> Díky!
>>>>
>>>> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>>>>>
>>>>> Určitě scrapy může i v tomto případě pomoct např. s tím jak pracuje s 
>>>>> concurrent requests a třebas autothrottle - to záleží na pravidlech toho 
>>>>> API které se bude konzumovat, co je dovoleno/jaké jsou limity. Pokud není 
>>>>> dovoleno dělat víc požadavků najednou tak bych tam asi scrapy ani netahal…
>>>>>
>>>>> Vítek
>>>>>
>>>>> 29. 11. 2018 v 22:09, Honza Javorek :
>>>>>
>>>>> Já bych řekl, že se specializuje na těžení a že má dost věci, které ti 
>>>>> to těžení usnadní, pokud jde o HTML. Pokud jde o JSON, nic usnadňovat 
>>>>> nepotrebujes, mas json.loads(), a pak ale pořad stavis na tom těžení.
>>>>>
>>>>> HJ
>>>>>
>>>>> On Thu, 29 Nov 2018 at 21:05, Petr Messner  
>>>>> wrote:
>>>>>
>>>>>> Ahoj,
>>>>>>
>>>>>> myslel jsem, že scrapy se specializuje na těžení dat z HTML. Říkáš, 
>>>>>> že se hodí i na JSON API?
>>>>>>
>>>>>> Petr
>>>>>>
>>>>>> čt 29. 11. 2018 v 20:47 odesílatel Honza Javorek <
>>>>>> ma...@honzajavorek.cz> napsal:
>>>>>>
>>>>>>> Ahoj,
>>>>>>>
>>>>>>> mirne offtopic, ale pokud muzu komentovat tu cast k

Re: [django-cs] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[Stanislav Vasko]

Všude narážím, že raději PSQL než MySQL, ale je někde takto pěkně a jasně 
ukázáno/řečeno/popsáno proč PSQL, ideálně praktické příklady. Knížek je 
hodně, ale ta než dorazí, to čekat nebudu. Nebo co bych měl určitě vědět a 
užít (viz např. views, i když je to jen uložené view, teď studuji 
materialized views).

Moc díky za nasměrování, večer budu chytrej jak rádio :)

On Friday, 30 November 2018 10:35:53 UTC+1, starenka wrote:
>
> Kdyz uz spamuju, 
>
> myslim, ze se tady vscihni shodnem, ze pokud ses svuj vlastni pan, tak 
> rozhodne brat postgres na ukor mysql. 
>
> Vyhod sou mraky, ale kdyz se bavime o migracich, tak napriklad kdyz se 
> neco stane pri migrovani schematu, tak postgres je schopnej delat ALTER 
> SCHEMA v migraci, takze to vrati nazpatek. U MySQL zustanes s databazi v 
> nejaky mezifazi a musis to jit uklizet. To nechces.
> ---
> 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, Nov 30, 2018 at 10:32 AM starenka .  > wrote:
>
>> Docka treba tady 
>> https://docs.djangoproject.com/en/2.1/ref/migration-operations/#runpython
>>  
>>
>> pouzijes to tak, ze das: `migrate appka cislomigrace_kam_se_chces_vratit`
>>
>> s.
>> ---
>> 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, Nov 30, 2018 at 10:30 AM starenka . > > wrote:
>>
>>> Cau, 
>>>
>>> migrace muzes delat i zpetny (tu ti ale nidko nevygeneruje a musis si ji 
>>> udelat sam). 
>>>
>>> cili neco jako 
>>>
>>> class Migration(migrations.Migration):
>>>
>>> dependencies = []
>>>
>>> operations = [
>>> migrations.RunPython(forwards_func, reverse_func),
>>> ]
>>>
>>>
>>>
>>> ---
>>> 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, Nov 30, 2018 at 10:28 AM Stanislav Vasko >> > wrote:
>>>
>>>> Zdravím,
>>>>
>>>> rád bych se poradil jak verzujete či zálohujete databázi během vývoje. 
>>>> Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem 
>>>> homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, 
>>>> cca 
>>>> 2 větve (master + devel) a na každé větvi commit po každé větší 
>>>> funkčnosti. 
>>>> Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy 
>>>> pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i 
>>>> funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám 
>>>> jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle 
>>>> migrací se vše provede. 
>>>>
>>>> Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a 
>>>> vůbec netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django 
>>>> napojit na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím 
>>>> zdrojový kód do stavu o několik migrací zpět, jak toto provedu i v MySQL 
>>>> databází? 
>>>>
>>>> Díky za tip či odkaz na dokumentaci.
>>>>
>>>> -- 
>>>> -- 
>>>> 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/890d65bd-a672-4b9d-aa73-016ad78d95a5%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/django-cs/890d65bd-a672-4b9d-aa73-016ad78d95a5%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>> Další možnosti najdete na https://groups.google.com/d/optout.
>>>>
>>>

-- 
-- 
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/4aa34fe2-cc3f-48f3-b145-abe496d3c1fe%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Volba databáze a její možnosti

[Stanislav Vasko]

V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z 
Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v 
SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE 
podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca 
6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji 
do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite 
nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst. 
Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto 
dobu aplikaci odstavit či házet errory.

Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL 
ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat 
do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z 
miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než 
cokoliv co spáchám já :)

Díky!

On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>
> Určitě scrapy může i v tomto případě pomoct např. s tím jak pracuje s 
> concurrent requests a třebas autothrottle - to záleží na pravidlech toho 
> API které se bude konzumovat, co je dovoleno/jaké jsou limity. Pokud není 
> dovoleno dělat víc požadavků najednou tak bych tam asi scrapy ani netahal…
>
> Vítek
>
> 29. 11. 2018 v 22:09, Honza Javorek >:
>
> Já bych řekl, že se specializuje na těžení a že má dost věci, které ti to 
> těžení usnadní, pokud jde o HTML. Pokud jde o JSON, nic usnadňovat 
> nepotrebujes, mas json.loads(), a pak ale pořad stavis na tom těžení.
>
> HJ
>
> On Thu, 29 Nov 2018 at 21:05, Petr Messner  > wrote:
>
>> Ahoj,
>>
>> myslel jsem, že scrapy se specializuje na těžení dat z HTML. Říkáš, že se 
>> hodí i na JSON API?
>>
>> Petr
>>
>> čt 29. 11. 2018 v 20:47 odesílatel Honza Javorek > > napsal:
>>
>>> Ahoj,
>>>
>>> mirne offtopic, ale pokud muzu komentovat tu cast kde budes bombardovat 
>>> to API, tak bych zvazil https://scrapy.org/ On si clovek casto nemysli 
>>> ze neco takovyho potrebuje, az kdyz do toho zabredne a trva to misto tri 
>>> dnu mesic, tak si uvedomi, ze misto requests mohl pouzit nejaky framework.
>>>
>>> Honza
>>>
>>> On Thu, Nov 29, 2018 at 8:19 PM Stanislav Vasko >> > wrote:
>>>
>>>> Díky za info. Jen zopakuji, že počet dotazů je pro Heureku skoro nic, 
>>>> proti jiným partnerům. Současné scrapování mám nejen povolené, ale hlavně 
>>>> tuto novou aplikaci budu napojovat (základní skripty jsou už hotové) přes 
>>>> API, které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto 
>>>> přímo 
>>>> postaveno.
>>>>
>>>> JSON soubory mně také napadly, vlastně bych mohl ukládat přímo odpovědi 
>>>> z API (je to JSON RPC), ale nevím jak praktické to je pro další 
>>>> zpracování. 
>>>> Musel bych pravidelně robotem tahat aktuální data denně vypočítat pak 
>>>> dlouhodobé statistiky, ale něco takového mně u DB řešení čeká asi také. 
>>>> Ještě mně napadlo, zda by nebylo efektivnější pro tyto účely využít nějaký 
>>>> skripty přímo v DB, tuším, že některé mají přímo "udělátka" na vypočítání 
>>>> dat, virtuálních tabulek apod. To by mi možná ušetřilo práci a vyřešilo 
>>>> nutnost neustále o data nějak pečovat.
>>>>
>>>> Kibana vypadá zajímavě, ale přiznám se, že o ní slyším poprvé a vůbec 
>>>> nevím jak to v tomto pojetí uchopit. Zkusím si něco nastudovat, ale raději 
>>>> bych se držel něčeho co zná každý a kdokoliv případně i poradí.
>>>>
>>>> Díky!
>>>>
>>>> On Thursday, 29 November 2018 20:05:21 UTC+1, Messa wrote:
>>>>>
>>>>> Ahoj,
>>>>>
>>>>> tohle scrapování určitě vidí Heureka strašně ráda. Ale to je tvůj boj 
>>>>> :)
>>>>>
>>>>> 60 tisíc záznamů denně? Hm, na to by stačil i JSON soubor. Paradoxně 
>>>>> by jeho zpracování mohlo být i rychlejší, než ze špatně navržené databáze.
>>>>>
>>>>> Což ostatně není špatný nápad, si ta data vylít a zpracovávat mimo. Je 
>>>>> to celkem častý postup (oddělení analytické db od transakční). Koneckonců 
>>>>> i 
>>>>> ten Dashboard může být generovaná statická webovka.
>>>>>
>>>>> Honzovo tip s Kibanou se mi taky líbí.
>>>>>
>>>>> Zkratka, podle mě tento objem ještě nijak neomezuje výběr technologie 
>>>>> :) (Doufám 

[django-cs] Jak verzovat databázi MySQL proti stavu zdrojového kódu?

[Stanislav Vasko]

Zdravím,

rád bych se poradil jak verzujete či zálohujete databázi během vývoje. 
Předpokládám, že to je moje elementární neznalost daná hlavně tím, že jsem 
homo-domo-samouk. K verzování používám GIT v naprosto primitivní formě, cca 
2 větve (master + devel) a na každé větvi commit po každé větší funkčnosti. 
Velice se mi hodí, že k danému stavu se mi uloží i SQLite soubor a tedy 
pokud chci kdykoliv skočit do kteréhokoliv bodu, mám ihned k dispozici i 
funkční databázi (byť pokaždé s jiným stavem dat). Deploy pak udělám 
jednoduše nahráním změněných soubor, pustím ./manage.py migrate a podle 
migrací se vše provede. 

Dneska je na obzoru projekt, kde nejspíše budu používat MySQL(PSQL) a vůbec 
netuším jak se přiblížit podobné funkčnosti. Zkusil jsem si Django napojit 
na MySQL, bez problémů. Migrace také v pořádku, ale pokud vrátím zdrojový 
kód do stavu o několik migrací zpět, jak toto provedu i v MySQL databází? 

Díky za tip či odkaz na dokumentaci.

-- 
-- 
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/890d65bd-a672-4b9d-aa73-016ad78d95a5%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Volba databáze a její možnosti

[Stanislav Vasko]

Díky za info. Jen zopakuji, že počet dotazů je pro Heureku skoro nic, proti 
jiným partnerům. Současné scrapování mám nejen povolené, ale hlavně tuto 
novou aplikaci budu napojovat (základní skripty jsou už hotové) přes API, 
které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto přímo 
postaveno.

JSON soubory mně také napadly, vlastně bych mohl ukládat přímo odpovědi z 
API (je to JSON RPC), ale nevím jak praktické to je pro další zpracování. 
Musel bych pravidelně robotem tahat aktuální data denně vypočítat pak 
dlouhodobé statistiky, ale něco takového mně u DB řešení čeká asi také. 
Ještě mně napadlo, zda by nebylo efektivnější pro tyto účely využít nějaký 
skripty přímo v DB, tuším, že některé mají přímo "udělátka" na vypočítání 
dat, virtuálních tabulek apod. To by mi možná ušetřilo práci a vyřešilo 
nutnost neustále o data nějak pečovat.

Kibana vypadá zajímavě, ale přiznám se, že o ní slyším poprvé a vůbec nevím 
jak to v tomto pojetí uchopit. Zkusím si něco nastudovat, ale raději bych 
se držel něčeho co zná každý a kdokoliv případně i poradí.

Díky!

On Thursday, 29 November 2018 20:05:21 UTC+1, Messa wrote:
>
> Ahoj,
>
> tohle scrapování určitě vidí Heureka strašně ráda. Ale to je tvůj boj :)
>
> 60 tisíc záznamů denně? Hm, na to by stačil i JSON soubor. Paradoxně by 
> jeho zpracování mohlo být i rychlejší, než ze špatně navržené databáze.
>
> Což ostatně není špatný nápad, si ta data vylít a zpracovávat mimo. Je to 
> celkem častý postup (oddělení analytické db od transakční). Koneckonců i 
> ten Dashboard může být generovaná statická webovka.
>
> Honzovo tip s Kibanou se mi taky líbí.
>
> Zkratka, podle mě tento objem ještě nijak neomezuje výběr technologie :) 
> (Doufám teda, že sqlite zvládá paralelní read.)
>
> Petr Messner
>
> 29. 11. 2018 v 12:59, Stanislav Vasko 
> >:
>
> Zdravím,
>
> pár let si v Django píšu menší aplikace pro svou práci a napsal jsem pár 
> řešení pro své klienty. Pro tyto účely používám SQLite a nikdy jsem 
> nenarazil na problém, navíc si mohu DB se zdrojákem snadno verzovat v GITu. 
> Nyní ale chci jeden ze svých projektů (analýza produktů na Heureka.cz) 
> zásadně rozšířit a rád bych si od začátku zvolil vhodný DB podvozek. Budu 
> 3x denně stahovat údaje o produktech (je jich asi 10 tisíc) přes Heureka 
> API. Kromě aktuální ceny produktu ještě budu potřebovat uložit data o 
> nabídkách jednotlivých e-shopů (cca 20 e-shopů na produkt, ukládat se bude 
> aktuální cena, pozice, skladovost a několik dalších parametrů). Tedy denně 
> 10.000 (produktů) x 3 (denně stahovat nabídky) x 20 (údajů o nabídce 
> konkrétního eshopu) záznamů. K tomu se určitě ještě něco přidá. Tato data 
> potřebuji dále zpracovávat. Typicky Dashboard s reportem aktuálně produktů 
> prodávaných pod určitou cenou, report firem prodávajících pod cenou nebo 
> náhled detailu produktu s historií průměrné a minimální ceny apod.
>
> Chtěl bych se zeptat zkušenějších programátorů na čem (případně navést i 
> detailněji) postavit DB podvozek. Problém asi není ani tak v tom data 
> uložit, ale hlavně abych z nich byl schopen v reálném čase něco sestavit. 
> Asi bude třeba vytvořit i nějaké roboty, kteří z dat za daný den/měsíc 
> připraví nějaká mezidata, vypočtou dashboard, protože přímé realtime 
> zpracování by bylo příliš pomalé. Nebo se mýlím?
>
> Díky za každý tip na DB, případně budu rád i za navedení na nějaký 
> relevantní zdroj informací o tom jakou a proč DB zvolit, případně kde mají 
> limity. Osobně studuji a váhám mezi SQLite, MySQL a PostgreSQL.
>
> Díky, Standa
>
> -- 
> -- 
> 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/7c78faf6-54b8-4130-95bb-293f6199f14e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-cs/7c78faf6-54b8-4130-95bb-293f6199f14e%40googlegroups.com?utm_medium=email_source=footer>
> .
> Další možnosti najdete na https://groups.google.com/d/optout.
>
>

-- 
-- 
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/d47d668b-4d47-4964-9f61-a96a6f0c9ef0%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Volba databáze a její možnosti

[Stanislav Vasko]

Zdravím,

pár let si v Django píšu menší aplikace pro svou práci a napsal jsem pár 
řešení pro své klienty. Pro tyto účely používám SQLite a nikdy jsem 
nenarazil na problém, navíc si mohu DB se zdrojákem snadno verzovat v GITu. 
Nyní ale chci jeden ze svých projektů (analýza produktů na Heureka.cz) 
zásadně rozšířit a rád bych si od začátku zvolil vhodný DB podvozek. Budu 
3x denně stahovat údaje o produktech (je jich asi 10 tisíc) přes Heureka 
API. Kromě aktuální ceny produktu ještě budu potřebovat uložit data o 
nabídkách jednotlivých e-shopů (cca 20 e-shopů na produkt, ukládat se bude 
aktuální cena, pozice, skladovost a několik dalších parametrů). Tedy denně 
10.000 (produktů) x 3 (denně stahovat nabídky) x 20 (údajů o nabídce 
konkrétního eshopu) záznamů. K tomu se určitě ještě něco přidá. Tato data 
potřebuji dále zpracovávat. Typicky Dashboard s reportem aktuálně produktů 
prodávaných pod určitou cenou, report firem prodávajících pod cenou nebo 
náhled detailu produktu s historií průměrné a minimální ceny apod.

Chtěl bych se zeptat zkušenějších programátorů na čem (případně navést i 
detailněji) postavit DB podvozek. Problém asi není ani tak v tom data 
uložit, ale hlavně abych z nich byl schopen v reálném čase něco sestavit. 
Asi bude třeba vytvořit i nějaké roboty, kteří z dat za daný den/měsíc 
připraví nějaká mezidata, vypočtou dashboard, protože přímé realtime 
zpracování by bylo příliš pomalé. Nebo se mýlím?

Díky za každý tip na DB, případně budu rád i za navedení na nějaký 
relevantní zdroj informací o tom jakou a proč DB zvolit, případně kde mají 
limity. Osobně studuji a váhám mezi SQLite, MySQL a PostgreSQL.

Díky, 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 zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/7c78faf6-54b8-4130-95bb-293f6199f14e%40googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.