Re: [django-cs] Django ORM

[PavelZet]

Dne neděle 2. září 2018 19:23:13 UTC+2 Honza Král napsal(a):
>
>
>
> On Sun, Sep 2, 2018, 19:14 PavelZet > 
> wrote:
>
>> Django je založen na třívrstvém modelu MVC.
>> Tedy v modulech (aplikacích) defaultně vytváří vrstvy:
>> models (M) -> views (C) -> a přidáváme ještě templates (V)
>> V Django asi bývá zvykem všechnu logiku zahrnout do modelů a hotovo.
>>
>
> Ne, django neni MVC, nikdy nebylo. Porusuje ty principy ve spouste mistech.
>

To už je asi slovíčkaření, jestli dobře známé MVC, MTV nebo MVT. Principy 
jsou obdobné, šlo hlavně o zmínění třívrstvého modelu (který se obecně 
osvědčil).

>
>> Obecně při vývoji není dobré psát dlouhé špagetové soubory (soubor a 
>> třída do 200 řádků, funkce do 40 řádků), avšak pro větší moduly tyto tři 
>> vrstvy budou málo.
>> Já to řeším mj. dalšími vrstvami repository a service.
>> model -> repository -> service -> view -> template
>>
>
> Tajmestvi toho je, ze zadna z tech vrstev nemusi byt v jednom souboru, nic 
> vas k tomu nenuti a muzete mit kod strukturovany (skoro) jak chcete.
>

Původně jsem chápal dlouhé špagetové soubory (models, views, ...) s mnoha 
kraťoučkými stereotypními funkcemi a třídami právě jako styl vývoje ražený 
Djangem.
Ale pokud to není "django-style", rozkládání jednotlivých tříd na soubory 
(jak se to dělá jinde) jen a jen uvítám.

Třeba models.py by měl sloužit jen jako výčet modelů a jednotlivé třídy 
modelů budou v jednotlivých souborech v podadresáři models (např. 
models/ProfileModel.py) ?
Nebo models.py vůbec není potřeba (pryč s ním) a místo něj stačí zmíněný 
podadresář models (se všemi modely po souborech) se souborem 
models/__init__.py (který původní models.py prakticky nahradí a ušetřím si 
psaní) ?

Je ale vhodné rozkládat na soubory i views.py, který neobsahuje třídy, ale 
jen funkce ?

Díky za reakci.


>> model: definuje jen jak entity dat vypadají, jaké mají vztahy atp., 
>> prakticky obsahuje jen fields a meta
>> repository: zahrnuje veškerou logiku úložiště (jako režii s SQL, soubory, 
>> sítí, pamětí...) a ukládá či poskytuje naplněné modely dále vrstvě service 
>> (service neřeší jak a odkud se modely berou)
>> service: obsahuje business logiku (jako ověření práv uživatele, přidává 
>> informaci o jazykové mutaci) a poskytuje konkrétní funkcionalitu vrstvě 
>> view nebo pro api
>> view: zpracovává request, messages..., a je prošpikovaná mnoha 
>> try-except... a z logiky pouze volá svou funkci ve vrstvě service
>> template: zobrazí obdržená data od view v html šabloně
>>
>
> Tohle je popis jednoho arbitrarniho rozdeleni jak to delaji nektere 
> produkty a frameworky, nikoli nejaka komplexni teorie, natoz dogma. Zkuste 
> premyslet spis nad tim jak to ma django a jak se to dela v djangu nez se 
> snazit namapovat jeden framework na druhy.
>

A jak to dělá django :) ?
Model by tedy měl:
- definovat strukturu entity (popis tabulky)
- uchovávat obsah entity (konkrétní data entity)
- určovat vzhled na frontendu (propojení s widgety)
- dolovat data z úložiště (funkce čtení z databáze, sítě, paměti atd., tedy 
zastává funkci repozitáře)?

A business logiku bych měl uchovávat v nové vrstvě service nebo kde ? Do 
models ani views se mi nehodí :(
 

>
>> aby models.py tak nebobtnal, vytvářím ještě
>> forms: definuje jednotlivé formuláře a poskytuje naplněné modely (jako 
>> property)
>> fields: jednotlivé *field pro formuláře se svou validací
>>
>
> Forms a modely maji uplne jiny vyznam a duvod, neni jakkoliv mozne rict, 
> ze vyvarim forms aby models nebobtnal.
>

Těch důvodů proč oddělit forms a fields je víc a docela se mi to osvědčilo.

>  
>

>> Dne neděle 2. září 2018 17:21:38 UTC+2 Honza Král napsal(a):
>>>
>>>
>>>
>>> On Sun, Sep 2, 2018 at 9:56 AM PavelZet  wrote:
>>>


 Dne středa 15. srpna 2018 10:22:23 UTC+2 Messa napsal(a):
>
> Ahoj,
>
> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>
>
> já teda nejsem Djangista, ale co jsem tak vypozoroval, tak Django ORM 
> je základní abstrakce pro data store a business logiku, díky tomu funguje 
> integrace s pluginy, adminem a tak. Když vezmeš Django a odečteš ORM a 
> cokoliv, co na ORM nějak navazuje, tak ti zbyde Flask :) Takže potom by 
> vlastně Django nedávalo žádnou přidanou hodnotu a z toho bych usoudil, že 
> 99,9% Django vývojářů bude používat ORM :)
>
>
 Django ORM má zastat funkce dolování dat a business? Takže nemá smysl 
 psát další vrstvy jako repository (dolování dat) a service (business 
 logika) ? Veškerá logika má tedy být v jednom dlouhém view (pro každý 
 modul)?
 Asi bych i tak tyto vrstvy (repository a service) zachoval. Přijde mi 
 přehlednější když views pouze zpracuje request a pak zavolá service. Views 
 se tak dost zúží.

>>>
>>> business logika rozhodne nema byt ve views, ale na modelu. Netusim, jak 
>>> do toho zapada Repository a co to ma spolecneho z dolovanim dat, muzes to 
>>> trochu rozvest?
>>>  
>>>
  

Re: [django-cs] Django ORM

[Honza Král]

On Sun, Sep 2, 2018, 19:14 PavelZet  wrote:

> Django je založen na třívrstvém modelu MVC.
> Tedy v modulech (aplikacích) defaultně vytváří vrstvy:
> models (M) -> views (C) -> a přidáváme ještě templates (V)
> V Django asi bývá zvykem všechnu logiku zahrnout do modelů a hotovo.
>

Ne, django neni MVC, nikdy nebylo. Porusuje ty principy ve spouste mistech.

>
> Obecně při vývoji není dobré psát dlouhé špagetové soubory (soubor a třída
> do 200 řádků, funkce do 40 řádků), avšak pro větší moduly tyto tři vrstvy
> budou málo.
> Já to řeším mj. dalšími vrstvami repository a service.
> model -> repository -> service -> view -> template
>

Tajmestvi toho je, ze zadna z tech vrstev nemusi byt v jednom souboru, nic
vas k tomu nenuti a muzete mit kod strukturovany (skoro) jak chcete.

>
> model: definuje jen jak entity dat vypadají, jaké mají vztahy atp.,
> prakticky obsahuje jen fields a meta
> repository: zahrnuje veškerou logiku úložiště (jako režii s SQL, soubory,
> sítí, pamětí...) a ukládá či poskytuje naplněné modely dále vrstvě service
> (service neřeší jak a odkud se modely berou)
> service: obsahuje business logiku (jako ověření práv uživatele, přidává
> informaci o jazykové mutaci) a poskytuje konkrétní funkcionalitu vrstvě
> view nebo pro api
> view: zpracovává request, messages..., a je prošpikovaná mnoha
> try-except... a z logiky pouze volá svou funkci ve vrstvě service
> template: zobrazí obdržená data od view v html šabloně
>

Tohle je popis jednoho arbitrarniho rozdeleni jak to delaji nektere
produkty a frameworky, nikoli nejaka komplexni teorie, natoz dogma. Zkuste
premyslet spis nad tim jak to ma django a jak se to dela v djangu nez se
snazit namapovat jeden framework na druhy.

>
> aby models.py tak nebobtnal, vytvářím ještě
> forms: definuje jednotlivé formuláře a poskytuje naplněné modely (jako
> property)
> fields: jednotlivé *field pro formuláře se svou validací
>

Forms a modely maji uplne jiny vyznam a duvod, neni jakkoliv mozne rict, ze
vyvarim forms aby models nebobtnal.

>
> Dne neděle 2. září 2018 17:21:38 UTC+2 Honza Král napsal(a):
>>
>>
>>
>> On Sun, Sep 2, 2018 at 9:56 AM PavelZet  wrote:
>>
>>>
>>>
>>> Dne středa 15. srpna 2018 10:22:23 UTC+2 Messa napsal(a):

 Ahoj,

 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?


 já teda nejsem Djangista, ale co jsem tak vypozoroval, tak Django ORM
 je základní abstrakce pro data store a business logiku, díky tomu funguje
 integrace s pluginy, adminem a tak. Když vezmeš Django a odečteš ORM a
 cokoliv, co na ORM nějak navazuje, tak ti zbyde Flask :) Takže potom by
 vlastně Django nedávalo žádnou přidanou hodnotu a z toho bych usoudil, že
 99,9% Django vývojářů bude používat ORM :)


>>> Django ORM má zastat funkce dolování dat a business? Takže nemá smysl
>>> psát další vrstvy jako repository (dolování dat) a service (business
>>> logika) ? Veškerá logika má tedy být v jednom dlouhém view (pro každý
>>> modul)?
>>> Asi bych i tak tyto vrstvy (repository a service) zachoval. Přijde mi
>>> přehlednější když views pouze zpracuje request a pak zavolá service. Views
>>> se tak dost zúží.
>>>
>>
>> business logika rozhodne nema byt ve views, ale na modelu. Netusim, jak
>> do toho zapada Repository a co to ma spolecneho z dolovanim dat, muzes to
>> trochu rozvest?
>>
>>
>>>
>>>
 V kontextu tohohle je psaní vlastních SQL příkazů asi něco jako
 programovat v C, když můžu to samé naprogramovat v Pythonu. Ale i to je
 někdy potřeba.

 SELECT ... ORDER BY id DESC LIMIT 1
> což je pomalejší a obecně o něco horší možnost ?


 Z čeho tak usuzuješ? Nevím o ničem rychlejším, než vlézt do id indexu,
 podívat se na poslední prvek (předpokládám, že ten index je seřazený), a
 fetchnout záznam, na který ten poslední prvek odkazuje. Nebo aspoň to si
 představuju, že SQL databáze udělá. Aspoň teda NoSQL databáze to tak dělají
 :)

>>>
>>> ano, pravda, omlouvám se za desinformaci.
>>>

 K debugování SQL dotazů apod. bych rád zmínil, že je fajn monitorovat
 aplikaci "zvenčí" - zapnout slow log v databázi, monitorovat pomalé
 requesty (např. nginx může do access logu uvádět celkovou dobu trvání
 requestu). Blackbox přístup mi tady přijde obecně robustnější než whitebox.

 Možná by bylo zajímavé v dev a staging prostředí uměle zvýšit latenci
 mezi appkou a databází, protože každá prasárna fungovala dobře, když běžela
 u vývojáře na localhostu :)

 Nebo přidat do testů nějaký middleware, který bude hlídat metriky okolo
 SQL dotazů.

 Nevýhoda byla, že musím myslet na escapování vstupů a poté musím
> mapovat výsledné pole na entitu. Toho bych se rád z časových důvodů 
> zbavil.


 Jsi programátor. Když na něco musíš myslet, tak to znamená, že sis na
 to nenapsal pomocnou funkci, nebo máš špatnou abstrakci.

 Petr Messner


 út 14. 8. 2018 v 

Re: [django-cs] Django ORM

[Honza Král]

On Sun, Sep 2, 2018 at 9:56 AM PavelZet  wrote:

>
>
> Dne středa 15. srpna 2018 10:22:23 UTC+2 Messa napsal(a):
>>
>> Ahoj,
>>
>> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>>
>>
>> já teda nejsem Djangista, ale co jsem tak vypozoroval, tak Django ORM je
>> základní abstrakce pro data store a business logiku, díky tomu funguje
>> integrace s pluginy, adminem a tak. Když vezmeš Django a odečteš ORM a
>> cokoliv, co na ORM nějak navazuje, tak ti zbyde Flask :) Takže potom by
>> vlastně Django nedávalo žádnou přidanou hodnotu a z toho bych usoudil, že
>> 99,9% Django vývojářů bude používat ORM :)
>>
>>
> Django ORM má zastat funkce dolování dat a business? Takže nemá smysl psát
> další vrstvy jako repository (dolování dat) a service (business logika) ?
> Veškerá logika má tedy být v jednom dlouhém view (pro každý modul)?
> Asi bych i tak tyto vrstvy (repository a service) zachoval. Přijde mi
> přehlednější když views pouze zpracuje request a pak zavolá service. Views
> se tak dost zúží.
>

business logika rozhodne nema byt ve views, ale na modelu. Netusim, jak do
toho zapada Repository a co to ma spolecneho z dolovanim dat, muzes to
trochu rozvest?


>
>
>> V kontextu tohohle je psaní vlastních SQL příkazů asi něco jako
>> programovat v C, když můžu to samé naprogramovat v Pythonu. Ale i to je
>> někdy potřeba.
>>
>> SELECT ... ORDER BY id DESC LIMIT 1
>>> což je pomalejší a obecně o něco horší možnost ?
>>
>>
>> Z čeho tak usuzuješ? Nevím o ničem rychlejším, než vlézt do id indexu,
>> podívat se na poslední prvek (předpokládám, že ten index je seřazený), a
>> fetchnout záznam, na který ten poslední prvek odkazuje. Nebo aspoň to si
>> představuju, že SQL databáze udělá. Aspoň teda NoSQL databáze to tak dělají
>> :)
>>
>
> ano, pravda, omlouvám se za desinformaci.
>
>>
>> K debugování SQL dotazů apod. bych rád zmínil, že je fajn monitorovat
>> aplikaci "zvenčí" - zapnout slow log v databázi, monitorovat pomalé
>> requesty (např. nginx může do access logu uvádět celkovou dobu trvání
>> requestu). Blackbox přístup mi tady přijde obecně robustnější než whitebox.
>>
>> Možná by bylo zajímavé v dev a staging prostředí uměle zvýšit latenci
>> mezi appkou a databází, protože každá prasárna fungovala dobře, když běžela
>> u vývojáře na localhostu :)
>>
>> Nebo přidat do testů nějaký middleware, který bude hlídat metriky okolo
>> SQL dotazů.
>>
>> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
>>> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
>>
>>
>> Jsi programátor. Když na něco musíš myslet, tak to znamená, že sis na to
>> nenapsal pomocnou funkci, nebo máš špatnou abstrakci.
>>
>> Petr Messner
>>
>>
>> út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:
>>
>>> Ahoj, chci se zeptat, zda
>>> SELECT ... WHERE id = max(id)
>>> jak ji dosáhnu?
>>> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING
>>> místo optimálního WHERE
>>> SELECT ... HAVING id = max(id)
>>> 4) proč všichni používají zápis .latest() (resp.
>>> .order_by(id)[:1].get()), který srovná celou tabulku a vybere poslední
>>> prvek formou
>>> SELECT ... ORDER BY id DESC LIMIT 1
>>> což je pomalejší a obecně o něco horší možnost ?
>>> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak
>>> psát ORM formu, abych dosáhl konkrétního SQL ?
>>> 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
>>> prostě nejdou?
>>> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
>>> náhradní řešení ?
>>>
>>> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
>>> napsaný rychle.
>>> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
>>> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
>>> Na to se hodí ORM.
>>>
>>> V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se
>>> dobře.
>>> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby
>>> vznikl optimální SQL dotaz, jaký si představuju. Takže časová úspora je
>>> zase tatam :(
>>>
>>> Díky za reakce znalých.
>>>
>>> --
>>> --
>>> 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
>>> 
>>> .
>>> 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 

Re: [django-cs] Django ORM

[Petr Messner]

Ahoj,

1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?


já teda nejsem Djangista, ale co jsem tak vypozoroval, tak Django ORM je
základní abstrakce pro data store a business logiku, díky tomu funguje
integrace s pluginy, adminem a tak. Když vezmeš Django a odečteš ORM a
cokoliv, co na ORM nějak navazuje, tak ti zbyde Flask :) Takže potom by
vlastně Django nedávalo žádnou přidanou hodnotu a z toho bych usoudil, že
99,9% Django vývojářů bude používat ORM :)

V kontextu tohohle je psaní vlastních SQL příkazů asi něco jako programovat
v C, když můžu to samé naprogramovat v Pythonu. Ale i to je někdy potřeba.

SELECT ... ORDER BY id DESC LIMIT 1
> což je pomalejší a obecně o něco horší možnost ?


Z čeho tak usuzuješ? Nevím o ničem rychlejším, než vlézt do id indexu,
podívat se na poslední prvek (předpokládám, že ten index je seřazený), a
fetchnout záznam, na který ten poslední prvek odkazuje. Nebo aspoň to si
představuju, že SQL databáze udělá. Aspoň teda NoSQL databáze to tak dělají
:)

K debugování SQL dotazů apod. bych rád zmínil, že je fajn monitorovat
aplikaci "zvenčí" - zapnout slow log v databázi, monitorovat pomalé
requesty (např. nginx může do access logu uvádět celkovou dobu trvání
requestu). Blackbox přístup mi tady přijde obecně robustnější než whitebox.

Možná by bylo zajímavé v dev a staging prostředí uměle zvýšit latenci mezi
appkou a databází, protože každá prasárna fungovala dobře, když běžela u
vývojáře na localhostu :)

Nebo přidat do testů nějaký middleware, který bude hlídat metriky okolo SQL
dotazů.

Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.


Jsi programátor. Když na něco musíš myslet, tak to znamená, že sis na to
nenapsal pomocnou funkci, nebo máš špatnou abstrakci.

Petr Messner


út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:

> Ahoj, chci se zeptat, zda
> SELECT ... WHERE id = max(id)
> jak ji dosáhnu?
> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING místo
> optimálního WHERE
> SELECT ... HAVING id = max(id)
> 4) proč všichni používají zápis .latest() (resp. .order_by(id)[:1].get()),
> který srovná celou tabulku a vybere poslední prvek formou
> SELECT ... ORDER BY id DESC LIMIT 1
> což je pomalejší a obecně o něco horší možnost ?
> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak psát
> ORM formu, abych dosáhl konkrétního SQL ?
> 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
> prostě nejdou?
> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
> náhradní řešení ?
>
> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
> napsaný rychle.
> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
> Na to se hodí ORM.
>
> V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se dobře.
> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby vznikl
> optimální SQL dotaz, jaký si představuju. Takže časová úspora je zase tatam
> :(
>
> Díky za reakce znalých.
>
> --
> --
> 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
> 
> .
> 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/CAK9Q5BQ_dMha5vq66WG751SEa_BRUN8J-kaPuy2UivVWXdj_Vg%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Django ORM

[starenka .]

Dik, to je fajn... :)

Ad django debug toolbar: asi fajn, ale ne vzdycky mas viewcka/neco
renderujes v browseru...

-
'aknerats'[::-1]

On Wed, Aug 15, 2018, 09:58 Václav Dohnal  wrote:

> Ještě doplním, že na ladění SQL/ORM se mi osvědčil python manage.py
> shell_plus --print-sql z knihovny
> https://github.com/django-extensions/django-extensions.
>
> Dne úterý 14. srpna 2018 14:12:46 UTC+2 Vítek Pliska napsal(a):
>>
>> Já doplním že v posledním djangu je snad i explain.
>>
>> Plus za mě jen print query moc nestačí, v debug toolbaru oceňuji např
>> zobrazení duplicitních dotazů což mi říká kde mi chybí select_related, kam
>> by bylo dobré dát prefetch e explain je tam také přehledný.
>>
>> V.
>>
>> Dne út 14. 8. 2018 12:35 uživatel starenka .  napsal:
>>
>>> Ostatni byli rychlejsi, tak jen pripomenu, ze dotazy neni treba
>>> "debugovat", ale staci 'print(qs.query)'.
>>>
>>> -
>>> 'aknerats'[::-1]
>>>
>>> On Tue, Aug 14, 2018, 12:32 Jan Walter  wrote:
>>>
 Nebudu opakovat již vyřčené, jen Ti můžu říct z pohledu člověka, který
 kdysi s SQL strávil hodně času a měl ho moc rád, že Django má ORM api moc
 hezký, zvykneš si rychle, a ujetej sql jazyk už nebudeš chtít pro běžný
 situace používat. Je to mnohem čitelnější, rychlejší na použití.

 Zkus a uvidíš.

 Btw, dobře nastavený indexy, integritní omezení, konfiguraci db atp.
 potřebuješ v obou případech.

 On Tue, 14 Aug 2018, 11:59 Martin Kubát,  wrote:

> Zdravím,
>
>1. django ORM je první volba. Django je tímto úzce spjato. Bude
>určitě existovat nějaká knihovna, která umí django+SQLAlchemy, ale moc 
> bych
>na to nevsázel. To už je pak lepší flask + SQLAlchemy.
>2. nevím o tom, ORM si toto řídí dle druhu vazby
>3. viz 4.
>4. asi zalezi na db enginu, ale na postgresu SELECT ... WHERE id =
>max(id) udělat nelze. Musis group by id a pak having, a to je
>rozhodne delsi, nez order by id. Na id je standardne index.
>5. asi jo, ale nedokazu poradit
>6. nektere veci proste nejdou, resi se to
>
> https://docs.djangoproject.com/pl/2.1/topics/db/sql/#performing-raw-sql-queries,
>nebo nizkourovnove primo sql.
>7. určitě. django ORM je jednoduché, i kdyz v posledních letech
>toho umí více a více. Na SQLAlchemy ale jestě úplně nemá. Namátkou 
> nativní
>polymorfismus.
>
> Debugovat dotazy z ORM je urcite dobre a po nejake praxi se i v ramci
> ORM budou psat dotazy rychleji a spravne.
>
> Hodně zdaru.
> MK
>
>
>
> út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:
>
>> Ahoj, chci se zeptat, zda
>>
>> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>> 2) jak lze určit zda použít INNER nebo OUTER JOIN ?
>> 3) když chci vyhledat entitu s posledním ID, tak nejlepší volbou je
>> forma
>> SELECT ... WHERE id = max(id)
>> jak ji dosáhnu?
>> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING
>> místo optimálního WHERE
>> SELECT ... HAVING id = max(id)
>> 4) proč všichni používají zápis .latest() (resp.
>> .order_by(id)[:1].get()), který srovná celou tabulku a vybere poslední
>> prvek formou
>> SELECT ... ORDER BY id DESC LIMIT 1
>> což je pomalejší a obecně o něco horší možnost ?
>> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak
>> psát ORM formu, abych dosáhl konkrétního SQL ?
>> 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci
>> které prostě nejdou?
>> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se
>> použít náhradní řešení ?
>>
>> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
>> napsaný rychle.
>> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím
>> mapovat výsledné pole na entitu. Toho bych se rád z časových důvodů 
>> zbavil.
>> Na to se hodí ORM.
>>
>> V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se
>> dobře.
>> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby
>> vznikl optimální SQL dotaz, jaký si představuju. Takže časová úspora je
>> zase tatam :(
>>
>> Díky za reakce znalých.
>>
>> --
>> --
>> 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
>> 

Re: [django-cs] Django ORM

[Vítek Pliska]

Já doplním že v posledním djangu je snad i explain.

Plus za mě jen print query moc nestačí, v debug toolbaru oceňuji např
zobrazení duplicitních dotazů což mi říká kde mi chybí select_related, kam
by bylo dobré dát prefetch e explain je tam také přehledný.

V.

Dne út 14. 8. 2018 12:35 uživatel starenka .  napsal:

> Ostatni byli rychlejsi, tak jen pripomenu, ze dotazy neni treba
> "debugovat", ale staci 'print(qs.query)'.
>
> -
> 'aknerats'[::-1]
>
> On Tue, Aug 14, 2018, 12:32 Jan Walter  wrote:
>
>> Nebudu opakovat již vyřčené, jen Ti můžu říct z pohledu člověka, který
>> kdysi s SQL strávil hodně času a měl ho moc rád, že Django má ORM api moc
>> hezký, zvykneš si rychle, a ujetej sql jazyk už nebudeš chtít pro běžný
>> situace používat. Je to mnohem čitelnější, rychlejší na použití.
>>
>> Zkus a uvidíš.
>>
>> Btw, dobře nastavený indexy, integritní omezení, konfiguraci db atp.
>> potřebuješ v obou případech.
>>
>> On Tue, 14 Aug 2018, 11:59 Martin Kubát,  wrote:
>>
>>> Zdravím,
>>>
>>>1. django ORM je první volba. Django je tímto úzce spjato. Bude
>>>určitě existovat nějaká knihovna, která umí django+SQLAlchemy, ale moc 
>>> bych
>>>na to nevsázel. To už je pak lepší flask + SQLAlchemy.
>>>2. nevím o tom, ORM si toto řídí dle druhu vazby
>>>3. viz 4.
>>>4. asi zalezi na db enginu, ale na postgresu SELECT ... WHERE id =
>>>max(id) udělat nelze. Musis group by id a pak having, a to je
>>>rozhodne delsi, nez order by id. Na id je standardne index.
>>>5. asi jo, ale nedokazu poradit
>>>6. nektere veci proste nejdou, resi se to
>>>
>>> https://docs.djangoproject.com/pl/2.1/topics/db/sql/#performing-raw-sql-queries,
>>>nebo nizkourovnove primo sql.
>>>7. určitě. django ORM je jednoduché, i kdyz v posledních letech toho
>>>umí více a více. Na SQLAlchemy ale jestě úplně nemá. Namátkou nativní
>>>polymorfismus.
>>>
>>> Debugovat dotazy z ORM je urcite dobre a po nejake praxi se i v ramci
>>> ORM budou psat dotazy rychleji a spravne.
>>>
>>> Hodně zdaru.
>>> MK
>>>
>>>
>>>
>>> út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:
>>>
 Ahoj, chci se zeptat, zda

 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
 2) jak lze určit zda použít INNER nebo OUTER JOIN ?
 3) když chci vyhledat entitu s posledním ID, tak nejlepší volbou je
 forma
 SELECT ... WHERE id = max(id)
 jak ji dosáhnu?
 zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING
 místo optimálního WHERE
 SELECT ... HAVING id = max(id)
 4) proč všichni používají zápis .latest() (resp.
 .order_by(id)[:1].get()), který srovná celou tabulku a vybere poslední
 prvek formou
 SELECT ... ORDER BY id DESC LIMIT 1
 což je pomalejší a obecně o něco horší možnost ?
 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak
 psát ORM formu, abych dosáhl konkrétního SQL ?
 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
 prostě nejdou?
 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
 náhradní řešení ?

 Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
 napsaný rychle.
 Nevýhoda byla, že musím myslet na escapování vstupů a poté musím
 mapovat výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
 Na to se hodí ORM.

 V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se
 dobře.
 ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby
 vznikl optimální SQL dotaz, jaký si představuju. Takže časová úspora je
 zase tatam :(

 Díky za reakce znalých.

 --
 --
 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
 
 .
 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 tuto diskusi zobrazit na webu, navštivte
>>> 

Re: [django-cs] Django ORM

[starenka .]

Ostatni byli rychlejsi, tak jen pripomenu, ze dotazy neni treba
"debugovat", ale staci 'print(qs.query)'.

-
'aknerats'[::-1]

On Tue, Aug 14, 2018, 12:32 Jan Walter  wrote:

> Nebudu opakovat již vyřčené, jen Ti můžu říct z pohledu člověka, který
> kdysi s SQL strávil hodně času a měl ho moc rád, že Django má ORM api moc
> hezký, zvykneš si rychle, a ujetej sql jazyk už nebudeš chtít pro běžný
> situace používat. Je to mnohem čitelnější, rychlejší na použití.
>
> Zkus a uvidíš.
>
> Btw, dobře nastavený indexy, integritní omezení, konfiguraci db atp.
> potřebuješ v obou případech.
>
> On Tue, 14 Aug 2018, 11:59 Martin Kubát,  wrote:
>
>> Zdravím,
>>
>>1. django ORM je první volba. Django je tímto úzce spjato. Bude
>>určitě existovat nějaká knihovna, která umí django+SQLAlchemy, ale moc 
>> bych
>>na to nevsázel. To už je pak lepší flask + SQLAlchemy.
>>2. nevím o tom, ORM si toto řídí dle druhu vazby
>>3. viz 4.
>>4. asi zalezi na db enginu, ale na postgresu SELECT ... WHERE id =
>>max(id) udělat nelze. Musis group by id a pak having, a to je
>>rozhodne delsi, nez order by id. Na id je standardne index.
>>5. asi jo, ale nedokazu poradit
>>6. nektere veci proste nejdou, resi se to
>>
>> https://docs.djangoproject.com/pl/2.1/topics/db/sql/#performing-raw-sql-queries,
>>nebo nizkourovnove primo sql.
>>7. určitě. django ORM je jednoduché, i kdyz v posledních letech toho
>>umí více a více. Na SQLAlchemy ale jestě úplně nemá. Namátkou nativní
>>polymorfismus.
>>
>> Debugovat dotazy z ORM je urcite dobre a po nejake praxi se i v ramci ORM
>> budou psat dotazy rychleji a spravne.
>>
>> Hodně zdaru.
>> MK
>>
>>
>>
>> út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:
>>
>>> Ahoj, chci se zeptat, zda
>>>
>>> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>>> 2) jak lze určit zda použít INNER nebo OUTER JOIN ?
>>> 3) když chci vyhledat entitu s posledním ID, tak nejlepší volbou je
>>> forma
>>> SELECT ... WHERE id = max(id)
>>> jak ji dosáhnu?
>>> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING
>>> místo optimálního WHERE
>>> SELECT ... HAVING id = max(id)
>>> 4) proč všichni používají zápis .latest() (resp.
>>> .order_by(id)[:1].get()), který srovná celou tabulku a vybere poslední
>>> prvek formou
>>> SELECT ... ORDER BY id DESC LIMIT 1
>>> což je pomalejší a obecně o něco horší možnost ?
>>> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak
>>> psát ORM formu, abych dosáhl konkrétního SQL ?
>>> 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
>>> prostě nejdou?
>>> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
>>> náhradní řešení ?
>>>
>>> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
>>> napsaný rychle.
>>> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
>>> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
>>> Na to se hodí ORM.
>>>
>>> V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se
>>> dobře.
>>> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby
>>> vznikl optimální SQL dotaz, jaký si představuju. Takže časová úspora je
>>> zase tatam :(
>>>
>>> Díky za reakce znalých.
>>>
>>> --
>>> --
>>> 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
>>> 
>>> .
>>> 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 tuto diskusi zobrazit na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/CA%2BL8erbnznv5YrMu4i5O4pis5O79LAEKQQ-shhEVYT9Vahgt4w%40mail.gmail.com
>> 
>> .
>> 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
> 

Re: [django-cs] Django ORM

[Jan Walter]

Nebudu opakovat již vyřčené, jen Ti můžu říct z pohledu člověka, který
kdysi s SQL strávil hodně času a měl ho moc rád, že Django má ORM api moc
hezký, zvykneš si rychle, a ujetej sql jazyk už nebudeš chtít pro běžný
situace používat. Je to mnohem čitelnější, rychlejší na použití.

Zkus a uvidíš.

Btw, dobře nastavený indexy, integritní omezení, konfiguraci db atp.
potřebuješ v obou případech.

On Tue, 14 Aug 2018, 11:59 Martin Kubát,  wrote:

> Zdravím,
>
>1. django ORM je první volba. Django je tímto úzce spjato. Bude určitě
>existovat nějaká knihovna, která umí django+SQLAlchemy, ale moc bych na to
>nevsázel. To už je pak lepší flask + SQLAlchemy.
>2. nevím o tom, ORM si toto řídí dle druhu vazby
>3. viz 4.
>4. asi zalezi na db enginu, ale na postgresu SELECT ... WHERE id =
>max(id) udělat nelze. Musis group by id a pak having, a to je rozhodne
>delsi, nez order by id. Na id je standardne index.
>5. asi jo, ale nedokazu poradit
>6. nektere veci proste nejdou, resi se to
>
> https://docs.djangoproject.com/pl/2.1/topics/db/sql/#performing-raw-sql-queries,
>nebo nizkourovnove primo sql.
>7. určitě. django ORM je jednoduché, i kdyz v posledních letech toho
>umí více a více. Na SQLAlchemy ale jestě úplně nemá. Namátkou nativní
>polymorfismus.
>
> Debugovat dotazy z ORM je urcite dobre a po nejake praxi se i v ramci ORM
> budou psat dotazy rychleji a spravne.
>
> Hodně zdaru.
> MK
>
>
>
> út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:
>
>> Ahoj, chci se zeptat, zda
>>
>> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>> 2) jak lze určit zda použít INNER nebo OUTER JOIN ?
>> 3) když chci vyhledat entitu s posledním ID, tak nejlepší volbou je forma
>> SELECT ... WHERE id = max(id)
>> jak ji dosáhnu?
>> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING místo
>> optimálního WHERE
>> SELECT ... HAVING id = max(id)
>> 4) proč všichni používají zápis .latest() (resp.
>> .order_by(id)[:1].get()), který srovná celou tabulku a vybere poslední
>> prvek formou
>> SELECT ... ORDER BY id DESC LIMIT 1
>> což je pomalejší a obecně o něco horší možnost ?
>> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak
>> psát ORM formu, abych dosáhl konkrétního SQL ?
>> 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
>> prostě nejdou?
>> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
>> náhradní řešení ?
>>
>> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
>> napsaný rychle.
>> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
>> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
>> Na to se hodí ORM.
>>
>> V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se dobře.
>> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby vznikl
>> optimální SQL dotaz, jaký si představuju. Takže časová úspora je zase tatam
>> :(
>>
>> Díky za reakce znalých.
>>
>> --
>> --
>> 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
>> 
>> .
>> 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 tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CA%2BL8erbnznv5YrMu4i5O4pis5O79LAEKQQ-shhEVYT9Vahgt4w%40mail.gmail.com
> 
> .
> 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 

Re: [django-cs] Django ORM

[Honza Král]

On Tue, Aug 14, 2018 at 10:59 AM PavelZet  wrote:

> Ahoj, chci se zeptat, zda
>
> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>

Ahoj, vsichni urcite ne, ale lide co pracuji s Djangem vetsinou ORM
pouzivaji.

2) jak lze určit zda použít INNER nebo OUTER JOIN ?
>

Tohle si primarne Django ORM urcuje sam podle toho, o co si pozadal.
Princip ORM je od toho aby uzivatele odstinila od syroveho SQL a mezi to
patri i takovehle veci. Mas nejaky konkretni priklad kde ORM rozhodlo pro
tvuj pripad spatne?



> 3) když chci vyhledat entitu s posledním ID, tak nejlepší volbou je forma
> SELECT ... WHERE id = max(id)
> jak ji dosáhnu?
> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING místo
> optimálního WHERE
> SELECT ... HAVING id = max(id)
>

Jsem zmateny - SELECT ... WHERE is = max(id) neni pro vetsinu databazi
validni konstrukce a k vyzvednuti posledniho zaznamu nefunguje, overoval
jsem pro postgres, pamatuju si neco spatne a mas tuhle konstrukci
vyzkousenou? Na jake databazi?


> 4) proč všichni používají zápis .latest() (resp. .order_by(id)[:1].get()),
> který srovná celou tabulku a vybere poslední prvek formou
> SELECT ... ORDER BY id DESC LIMIT 1
> což je pomalejší a obecně o něco horší možnost ?
>

Doporucil bych se podivat na provadeci plan ve tve databazi, ale silne
pochybuju, ze jakakoliv databaze bude srovnavat celou tabulku kdyz chci jen
jeden prvek. Obzvlast kdyz mam nad polickem id index, v tom pripade se
jedna o trivialni pristup k tomu indexu a iteraci pres nej s LIMIT 1.


> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak psát
> ORM formu, abych dosáhl konkrétního SQL ?
>

opet - tohle popira byhody ORM, jestli chces psat vlastni SQL, pis vlastni
SQL, nemelo by to ale byt vubec potreba.

6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
> prostě nejdou?
>

Jsou samozrejme veci ktere jeste nejdou primo pres ORM ale mas vzdy k
dispozici metodu raw (0) ktera ti umozni napsat si kompletne svuj SQL dotaz.

0 - https://docs.djangoproject.com/en/2.1/topics/db/sql/


> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
> náhradní řešení ?
>

z prakticke zkusenosti o zadnem pripadu nevim ale urcite se nejake najdou.
Pro me je to casto signal, ze se neco nedeje


>
> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
> napsaný rychle.
> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
> Na to se hodí ORM.
>
https://docs.djangoproject.com/en/2.1/topics/db/sql/
Ne, ORM je o necem skutecne jinem. Na escapovani je proste db api ktere ti
escapuje vstupy zcela automaticky pokud ho pouzivas spravne - s parametery
-  a nelepis vysledny SQL dotaz jako string. To neni NIKDY akceptovatelne
reseni.

Mapovani na entitu muzes delat nezavisle.

V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se dobře.
> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby vznikl
> optimální SQL dotaz, jaký si představuju. Takže časová úspora je zase tatam
> :(
>

Opet nejaky konkretni pripad kde django vygenerovalo dotaz ktery je radove
min efektivni nez to, co si z nej pak udelal? Bez takovych prikladu je
tohle akademicka diskuze kde cisla nejsou na tve strane - Django ORM
pouziva naprosto drtiva vetsina Django webu bez vetsich problemu...


> Díky za reakce znalých.
>
> --
> --
> 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/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
> 
> .
> 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/CADoCwr0p3dD2uiwWtzP14y2HiprD6c2muBuuN1_eKyaM5nLd%3DA%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Django ORM mocking

[Martin Tirsel]

Parada, jednoduche a riesi presne co potrebujem. Dve kratucke test 
metody, ziadny pristup do DB a mam otestovane co treba.


Mam taky pocit, ze som v mojich zaciatkoch Djanga aj narazil na nejaku 
prednasku, ktora nieco take doporucovala robit, ale to som este velmi 
nechapal suvislostiam :)


Dakujem,
Martin

On 08/15/2014 06:28 PM, Honza Král wrote:

Me prislo vzdy nejjednodussi abstrahovat vytvareni querysetu do
samostatne metody/funkce a pak proste zkontrolovat ze je spravne
sestaveny - tedy ze ma order_by nastavene na 'id' atp. Pak staci na
mockovat tuhle metodu abych jeste zjistil zda je volana spravne a
pripadne aby vracela primo list nejakych modelu ktere chci (idealne
ktere ani nejsou ulozene v DB)
Honza Král
E-Mail: honza.k...@gmail.com
Phone:  +420 606 678585


2014-08-15 13:25 GMT-03:00 Martin Tirsel :

Zdarec,

neviete o nejakej vhodnej moznosti ako testovat a mockovat ORMko? Mam totiz
pomerne vela zavislosti medzi modelami a na to naviazane rozne eventy, takze
ak potrebujem otestovat napr. to, ci ma queryset nastavene spravne radenie v
nejakej funkcii, tak bud pol hodiny pripravujem prostredie alebo sa pol
hodiny stracam v helper funkciach, ktore mi nastavuju xy roznych stavov
databazy...

Napr.:

def foo(id):
   ...
   results = BarModel.objects.filter(...).exclude(...).select_related(..)
   ...

Tu potrebujem napr. zistit, ci pri zavolani foo() su zaznamy z BarModel s
radenim .order_by('-id').  Alebo ci exclude je volane s parametrom foo
nastavenym na hodnotu bar a podobne.

Zatial som na nic pouzitelne nenarazil a mockovat explicitne kazdu cast
celej retaze mi tiez nepride extra produktivne.

Martin

--
--
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.
Další možnosti najdete na adrese 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.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Django ORM mocking

[Martin Tirsel]

Zdarec,

neviete o nejakej vhodnej moznosti ako testovat a mockovat ORMko? Mam 
totiz pomerne vela zavislosti medzi modelami a na to naviazane rozne 
eventy, takze ak potrebujem otestovat napr. to, ci ma queryset nastavene 
spravne radenie v nejakej funkcii, tak bud pol hodiny pripravujem 
prostredie alebo sa pol hodiny stracam v helper funkciach, ktore mi 
nastavuju xy roznych stavov databazy...


Napr.:

def foo(id):
  ...
  results = BarModel.objects.filter(...).exclude(...).select_related(..)
  ...

Tu potrebujem napr. zistit, ci pri zavolani foo() su zaznamy z BarModel 
s radenim .order_by('-id').  Alebo ci exclude je volane s parametrom 
foo  nastavenym na hodnotu bar a podobne.


Zatial som na nic pouzitelne nenarazil a mockovat explicitne kazdu cast 
celej retaze mi tiez nepride extra produktivne.


Martin

--
--
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.
Další možnosti najdete na adrese https://groups.google.com/d/optout.