abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 22:44 | Bezpečnostní upozornění

    NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.

    Ladislav Hagara | Komentářů: 0
    včera 21:00 | IT novinky

    Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.

    Ladislav Hagara | Komentářů: 0
    včera 13:33 | Komunita

    Dle analytics.usa.gov je za posledních 90 dnů 6,2 % přístupů k webových stránkám a aplikacím federální vlády Spojených států z Linuxu.

    Ladislav Hagara | Komentářů: 0
    20.7. 17:44 | Zajímavý článek

    Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.

    Ladislav Hagara | Komentářů: 3
    20.7. 00:33 | Bezpečnostní upozornění

    V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.

    Ladislav Hagara | Komentářů: 15
    20.7. 00:22 | Komunita

    Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.

    Ladislav Hagara | Komentářů: 0
    19.7. 13:22 | Komunita

    Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.

    Ladislav Hagara | Komentářů: 1
    18.7. 14:00 | Zajímavý článek

    Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    18.7. 12:00 | Nová verze

    V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.

    Ladislav Hagara | Komentářů: 2
    17.7. 18:44 | Zajímavý článek

    Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).

    Ladislav Hagara | Komentářů: 1
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (27%)
     (21%)
     (4%)
     (8%)
     (2%)
     (4%)
     (4%)
     (31%)
    Celkem 52 hlasů
     Komentářů: 9, poslední včera 15:56
    Rozcestník
    Štítky: není přiřazen žádný štítek


    Vložit další komentář
    3.10.2015 19:30 Odin1918 | skóre: 6 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Databáza ľubovoľná (MySQL nepovažujem za databázu), ja som pre ukážky použil SQLite.
    Uff.
    mirec avatar 3.10.2015 19:47 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM

    Mysql má veľa vecí implementovaných akože. SQLite sa na nič nehraje, je to embedded blbosť a tým to končí.

    Urobiť ORM nad MySQL je na vytrhanie vlasov. Chcem napr. cez ORM získať komentáre najnovších 10 užívateľov:

    Comment.objects.filter(author__in=User.objects.order_by('-id')[:10])

    MySQL sa síce tvári, že subselecty podporuje, ale v subselecte sa nedá použiť napr. limit. SQL kompilátor musí vziať do úvahy toto obmedzenie a vykonať najskôr vnútorný select a potom použiť operátor IN s vymenovanými hodnotami. Lenže mysql má akosi limit na vymenované hodnoty. Korektne sa to vyriešiť nedá, môžem len dúfať že to väčšinou pôjde.

    Kapitolou samou o sebe je v mysql kódovanie. Do varchar(100) nemôžem vložiť 100 znakov, ale dĺžka je v bytoch. Ako to validovať pred uložením? No korektne veľmi ťažko. Čo vlastne zobraziť užívateľovi? Používateľ zadá 80 unicode znakov a validácia bude kričať, človeče pozor, môžeš max 100 bytov, ale spočítaj si byty nie znaky.

    MySQL je proste typická ukážka "celé zle". Nevadí mi keď je niečo sprosté. Vadí mi keď je implementácia odfláknutá a nerieši špeciálne situácie.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    3.10.2015 19:56 Odin1918 | skóre: 6 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    S vasim nazorem na mysql absolutne souhlasim a podepisuji jej. ;-) Pozastavil jsem se nad tim, ze nejdrive reknete, ze mysql neni databaze, a pak si vyberete pouziti sqlite. Vyznelo to vtipne. Ale uznavam, ze pro vas ucel sqlite plne dostacuje. Osobne preferuji postgresql. Je to open source projekt se super komunitou a v poslednich verzich ma i funkce, ktere drive byly vysadou relativne drahych alternativ.
    mirec avatar 3.10.2015 20:07 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM

    V príkladoch zvyčajne volím SQLite, ak niekto chce narýchlo vyskúšať kód nemusí nič riešiť.

    Konkrétne na MySQL nadávam pretože mám rád ľudí ;-) Nedávno sme v práci použili na väčšom projekte MySQL (nie môj výber). Nakoniec sme sa dostali do stavu keď sme riešili viacej MySQL špecifických problémov než zvyšné problémy aplikácie. Takže za pochodu sme migrovali na PostgreSQL. Fakt ak máte možnosť vyhnite sa MySQL. Fakt, fakt, možno na začiatku vyzerá fajn ale tie bugy sa tam nabaľujú a nabaľujú.

    Na malé projekty kde si zákazník chce editovať web s max 20 podstránkami používame MySQL ... ale postaršiu verziu. Chcel by som vidieť toho experta ktorý riešil InnoDB. Mať podporovaný fulltext iba v Myisam je na zbláznenie. No čo si mám vybrať, referenčnú integritu, či fulltext? :-D Veľké fulltextové riešenia ako lucene na web kde príde 10 ľudí denne a má dokopy 20 podstránok je kanón na vrabca.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    3.10.2015 21:07 origaPL
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    na ty pindy o SQL se da odpovedet jen tim znamym vtipem z 80. let.

    obchodni manager: nase databaze pouziva SQL standard

    otazka z plena: a ktery z nich ?
    3.10.2015 21:58 Odin1918 | skóre: 6 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Take si pamatuji dlouha patrani po pricinach chyb v mysql. ;-) Postgresql je jasna volba.
    Takže za pochodu sme migrovali na PostgreSQL
    +100
    Josef Kufner avatar 4.10.2015 14:56 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Namísto Lucene můžeš použít Sphinx. S MySQL to spolupracuje docela pěkně, je to jednoduché, přímočaré a bez překomplikované kupy Java hnoje kolem.
    Hello world ! Segmentation fault (core dumped)
    3.10.2015 21:02 origaPL
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Osobne preferuji postgresql.

    Vlastne me to ani neprekvapuje, protoze jste jen nekonzistentni 1/2 sudetonemecky blafal.

    Takze pro Vasi informaci. Postgres byla vyvinuta na statni univerzite a vyvoj byl placen z penez danovych poplatniku. Michael Stonebraker (vedouci toho projektu) je typicky zcela zrejme pripad vysokoskolskeho ucitele, ktery by v privatnim sektoru umrel hlady.
    3.10.2015 21:48 Odin1918 | skóre: 6 | blog: Valhalla
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Rad te prekvapim. Pouzivam Linux i spoustu software od gnu a netusim, zda Torvalds a Stallman studovali a pracovali ve statem financovanych institucich ci ne. Mezi lidmi, kteri pracuji na statem financovane AVCR, kterou povazuji za nehodnou existence, mam spoustu pratel.

    Vis, svet neni jen politika a penize. U postgresu mne zajima to, co umi, a ne to, z ceho vznikl.
    4.10.2015 01:14 čobolo-tobolo
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    >> Takze pro Vasi informaci. Postgres byla vyvinuta na statni univerzite a vyvoj byl placen z penez danovych poplatniku. Michael Stonebraker (vedouci toho projektu) je typicky zcela zrejme pripad vysokoskolskeho ucitele, ktery by v privatnim sektoru umrel hlady.

    A?

    Keď mi štát zobere výpalné a postaví za ne napríklad cestu, nemám právo ju používať? A ktorú cestu mám teda používať keď si štát na stavbu ciest uzurpoval monopol?
    4.10.2015 02:38 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Michael Stonebraker (vedouci toho projektu) je typicky zcela zrejme pripad vysokoskolskeho ucitele, ktery by v privatnim sektoru umrel hlady.
    Zajimave, ze stihl zalozit/prodat hned nekolik firem.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    okbob avatar 4.10.2015 09:38 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Michael Stonebraker je velice chytrý člověk, který umí se úspěšně uplatnil jak v akademické sféře, tak ve sféře komerční. Výzkum primárně financoval ze státních financí (NASA, USA Army), ale USA na tom určitě neprodělalo. Je to jeden z lidí, díky kterému ve zpracování dat hrají prim USA a jeho tým byl (dnes tým jeho syna) je o generaci před ostatními. Podílel se na výzkumu objektově relačních databází (Postgres), proudových databází, sloupcových databází, dneska databází polí. S jakoukoliv generací si udělal jméno a navíc dokázal velice výhodně prodat (komercializovat) prototyp, který na v rámci výzkumu vytvořil. Mám pocit, že to bude něco dohromady nad miliardu dolarů - a to nepočitám nevyčíslitelné částky za citace a publicitu mateřské univerzity. Navíc jeho studenti se uplatnili jako inženýři - např. moderní optimalizátor v Oraclu je napsaný jeho studentem, který psal optimalizér pro Postgres.

    Je ale faktem, že za jeho úspěchem stojí z velké míry situace v USA koncem 70let, kdy se v USA univerzitní výzkum velice štědře podporoval ze státních fondů - a po dekádě této podpory USA celému světu ukázalo záda (v IT).
    4.10.2015 12:29 origaPL
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    dekuji za vecne shrnuti problematiky. Muj prispevek byl samozrejme takovym rypnutim proti uzivateli, ktery se neustale nediferencovane navazi do statniho sektoru.

    Ale dost politiky.

    Kdyz uz jste tady, vratme se k tematu blogu. Autor si stezuje na na problemy s mysql pod ORM. Problem vidim v pouziti ORM jako zasadne 'problematicke' technologii, jak se vyhnout specifikum jednotlivych databazi. ORM ma jako vsechny 'obecne' nastroje ten problem, ze muze byt jen horsi ci lepsi spolecny jmenovatel vlastnosti objektu, ktere 'znormalizovane' nabizi dal. Existuji i jine metody, jak vyse uvedeny cil dosahnout (software je mozno provozovat s vice databazemi). Co preferujete?
    mirec avatar 4.10.2015 14:23 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Autor si stezuje na na problemy s mysql pod ORM.

    Nepovažoval by som ich za problémy s ORM. Sú to všeobecné problémy. To, že nemôžem použiť fulltext pri InnoDB nemá s ORM nič spoločné. To, že nastavím poľu dĺžku 100 znakov a databáza mi negarantuje, že tam môžem uložiť 100 znakov nie je problém ORM. Mne to však robí zásadný problém, že nemôžem validovať formulár pred pokusom o uloženie. Nemôžem tomu kto zadáva do poľa nejaký text garantovať akú dĺžku môžem uložiť do db. V žiadnom prípade netolerujem ak mi databáza vyhodí bez príčiny výnimku keď jej dám validný vstup, netolerujem keď mi v tichosti odstrihne znaky v reťazci a už vôbec nie ak mi unicode reťazec odstrihne v polovici znaku.

    Problem vidim v pouziti ORM jako zasadne 'problematicke' technologii, jak se vyhnout specifikum jednotlivych databazi.

    To netvrdím. Je mi relatívne jedno, či moja aplikácia beži v jedinej správnej db, alebo na všetkom možnom. Stačí mi, že beží s DB ktorú som si nainštaloval na server. ORM používam kvôli úplne iným vlastnostiam a tu sa trochu rozpíšem.

    Ako som na začiatku spomínal Django ORM som nemal zo začiatku rád. Bola obmedzená a naučiť sa ju trvalo dlho (porovnateľne dlho s učením sa samotného SQL). V prvom rade nie je to žiadna zázračná vecička ktorú hneď začnete používať a ste majstri sveta. Je to samostatný jazyk nad SQL a jeho učenie trvá aj v prípade znalosti SQL približne rovnakú dobu.

    Dlhú dobu som ORM nútil do vecí ktoré neovládalo (použitím metódy extra, alebo v najhoršom prípade napísaním celého raw SQL a obalením do objektov). V súčasnosti to už robím len veľmi výnimočne. Pred pár dňami som robil selecty nad zoznamkou a filtrovanie. Vyšiel z toho dotaz ktorý mal po rozpísaní asi 100 riadkov. Dosť komplikovaný s pár joinmi, pár CASEmi, ale bol presne taký ako by som ho napísal ručne až na názvy aliasov tabuliek. Čas kým som vyskladal dotaz bol porovnateľný s vyskladaním SQL dotazu, zase žiadna zázračna skratka na všetko sa nekoná.

    Teraz k silným stránkam: postupne budem skladať trochu zložitejší dotaz:

    qs = (Article.objects
        .all())
    
    SELECT
      "article_article"."id",
      "article_article"."title",
      "article_article"."slug",
      "article_article"."category_id",
      "article_article"."perex",
      "article_article"."annotation",
      "article_article"."content",
      "article_article"."author_id",
      "article_article"."authors_name",
      "article_article"."pub_time",
      "article_article"."updated",
      "article_article"."published",
      "article_article"."top",
      "article_article"."image"
    FROM "article_article"
    WHERE
      (
        "article_article"."published" = True AND
        "article_article"."pub_time" <= 2015-10-04 11:45:29.155657
      )
    ORDER BY "article_article"."id" DESC
    

    Implicitne sa vyberajú všetky polia. Vo väčšine prípadov je to presne to, čo potrebujem. Ak mi však vadí nejaké pole (napr. content obsahuje priveľký text a na zoznam ho nepotrebujem) stačí použiť defer.

    qs = (Article.objects
        .defer('content'))
    
    # rovnaké SQL akurát vynechaný stĺpec content

    Ak chcem len vybrané stĺpce môžem použiť metódu only:

    qs = (Article.objects
        .only('title'))
    
    SELECT
      "article_article"."id",
      "article_article"."title"
    FROM "article_article"
    WHERE ("article_article"."published" = True AND "article_article"."pub_time" <= 2015-10-04 11:49:48.960429)
    ORDER BY "article_article"."id" DESC

    U článkov mám štandarnde nastavené filtrovanie publikovaných. Ak by som chcel všetky použijem all_articles

    qs = (Article.all_articles
        .only('title'))
    
    SELECT
      "article_article"."id",
      "article_article"."title"
    FROM "article_article"

    Povedzme, že chcem vo výpise zobraziť aj kategórie:

    qs = (Article.all_articles
        .select_related('category')
        .only('title', 'category'))
    
    SELECT
      "article_article"."id",
      "article_article"."title",
      "article_article"."category_id",
      "article_category"."id",
      "article_category"."name",
      "article_category"."slug",
      "article_category"."description"
    FROM "article_article"
    INNER JOIN "article_category" ON ( "article_article"."category_id" = "article_category"."id" )

    Z kategórií sú zase implicintne vyberané všetky stĺpce. Ak by som chcel len názov kategórie tak do only zapíšem namiesto 'category' hodnotu 'category__name'.

    Ďalej by som mohol chcieť napríklad zobraziť počet komentárov k článkom:

    qs = (Article.all_articles
      .select_related('category')
      .only('title', 'category__name')
      .annotate(comments_count=Count('comments')))
    
    SELECT
      "article_article"."id",
      "article_article"."title",
      "article_article"."category_id",
      COUNT("django_comments"."id") AS "comments_count",
      "article_category"."id",
      "article_category"."name"
    FROM "article_article"
    LEFT OUTER JOIN "django_comments"
      ON ( "article_article"."id" = "django_comments"."object_id" AND ("django_comments"."content_type_id" = 13) )
    INNER JOIN "article_category"
      ON ( "article_article"."category_id" = "article_category"."id" )
    GROUP BY
      "article_article"."id",
      "article_article"."title",
      "article_article"."category_id",
      "article_category"."id",
      "article_category"."name"

    Z príkladov je asi jasné, že django ORM ušetrí veľkú časť písania kódu. O rozmýšľaní to však neplatí ;-)

    V poslednom príklade si asi zaslúži jedná časť joinu vysvetlenie. Konkrétne ide o "django_comments"."content_type_id" = 13. Django umožňuje používať generické foreign kľúče. Všetky tabuľky, ktoré django vytvorí majú zároveň záznam v tabuľke django_content_type. Ak mám generické komentáre, ktoré môžu byť ku každému objektu v databáze stačí mi urobiť foreign key content_type_id na túto tabuľku a object_id na tabuľku ku ktorej je priradený komentár.

    V príkladoch som pužil dokopy 3 metódy čo je len špička ľadovca. Bez problémov môžem vyskladať omnoho zložitejšie výrazy. Stále mám pomerne slušnú kontrolu nad dotazmi a čo je najdôležitejšie dotazy vyzerajú prakticky rovnako ako keby som ich písal ručne. Dotazy sa reálne spúšťajú až keď cez queryset iterujem.

    Skutočnou killer featurou je pre mňa možnosť pracovať s predžúvaným dotazom. Môžem postupne aplikovať filtre:

    if only_published:
        qs = qs.filter(is_published=True)
    if only_author:
        qs = qs.filter(author=only_author)
    ...

    Nad takto predžúvaným dotazom si môžem vytiahnuť štatistiky (ORM mi automaticky doplní všetky tie nechutnosti ako group by kde by som musel všetko vymenúvať znovu). Môžem nad predžúvaným querysetom vykonať limit a poslať do šablóny len časť ktorá ma zaujíma (limit, offset, alebo rownum between, proste čo daná db podporuje).

    Existuji i jine metody, jak vyse uvedeny cil dosahnout (software je mozno provozovat s vice databazemi).

    Aké? Nie že by to bolo pre mňa nejako dôležité, ale rád sa učím nové veci. Kvôli tomu vlastne blogujem na abclinuxu.cz, je tu skvelá komunita ktorá sa nehanbí kritizovať. V práci programujem sám, takže nejaký feedback zbieram už len kvôli tomu aby som sa dozvedel čo v mojom kóde / štýle programovania zlepšiť. Občas oponujem, ale neznamená to, že by som argument nebral do úvahy ;-)

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 4.10.2015 14:52 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    To, že nastavím poľu dĺžku 100 znakov a databáza mi negarantuje, že tam môžem uložiť 100 znakov
    Zkusil jsem si to, funguje to správně:
    DROP TABLE IF EXISTS `a`;
    
    CREATE TABLE `a` (
      `str1` varchar(10) COLLATE utf8mb4_czech_ci NOT NULL,
      `str2` varchar(10) COLLATE utf8_czech_ci NOT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_czech_ci;
    
    INSERT INTO `a` (`str1`, `str2`) VALUES
    ('1234567890', '1234567890'),
    ('qwertyuiop', 'qwertyuiop'),
    ('+ěščřžýáíé', '+ěščřžýáíé'),
    ('+ěščřžýáíé+ěščřžýáíé', '+ěščřžýáíé+ěščřžýáíé');
    
    SELECT * FROM `a`;
    
    DROP TABLE IF EXISTS `a`;
    
    CREATE TABLE `a` (
      `str1` varchar(10) COLLATE utf8mb4_czech_ci NOT NULL,
      `str2` varchar(10) COLLATE utf8_czech_ci NOT NULL
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_czech_ci;
    
    INSERT INTO `a` (`str1`, `str2`) VALUES
    ('1234567890', '1234567890'),
    ('qwertyuiop', 'qwertyuiop'),
    ('+ěščřžýáíé', '+ěščřžýáíé'),
    ('+ěščřžýáíé+ěščřžýáíé', '+ěščřžýáíé+ěščřžýáíé');
    
    SELECT * FROM `a`;
    V obou případech dostanu výsledek:

    str1str2
    12345678901234567890
    qwertyuiopqwertyuiop
    +ěščřžýáíé+ěščřžýáíé
    +ěščřžýáíé+ěščřžýáíé

    MySQL 5.6.
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 4.10.2015 15:03 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM

    Máme staršiu verziu bez utf8mb4.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 4.10.2015 15:09 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Použil jsem i prosté utf8.
    Hello world ! Segmentation fault (core dumped)
    Bedňa avatar 8.10.2015 21:52 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    A čo to v MySQL nejde riešiť? Rád by som sa nechal poučiť.
    KERNEL ULTRAS video channel >>>
    mirec avatar 8.10.2015 22:25 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM

    XML, JSON (áno nejaká paródia na JSON tam je, ale nedá sa napríklad indexovať), funkcionálne indexy, ACID, indexy nad viewmi, sekvencie, spatiálne vyhľadávanie (postgis, viem, že má aj mysql ale nekompletné), perl / python / javascript triggery, odolnosť voči poškodeniu dát, ...

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 4.10.2015 14:59 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    MySQL sa síce tvári, že subselecty podporuje, ale v subselecte sa nedá použiť napr. limit.
    CREATE TABLE `a` (
      `str1` varchar(10) COLLATE utf8mb4_czech_ci NOT NULL,
      `str2` varchar(10) COLLATE utf8_czech_ci NOT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_czech_ci;
    
    INSERT INTO `a` (`str1`, `str2`) VALUES
    ('1234567890', '1234567890'),
    ('qwertyuiop', 'qwertyuiop'),
    ('+ěščřžýáíé', '+ěščřžýáíé');
    
    SELECT * FROM (SELECT * FROM `a` LIMIT 2) AS `b`;
    str1		str2
    1234567890	1234567890
    qwertyuiop	qwertyuiop
    
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 4.10.2015 15:03 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM

    Máme staršiu verziu ktorá to považuje za chybu syntaxe.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Josef Kufner avatar 4.10.2015 15:09 Josef Kufner | skóre: 70
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Upgraduj a můžeš přestat nadávat ;)
    Hello world ! Segmentation fault (core dumped)
    mirec avatar 4.10.2015 15:14 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Časové rady v django ORM

    Čo urobím s pokazenými DDL? MySQL musí kvôli tomu locknúť tabuľky (down time), nedá sa to uzatvoriť do transakcie (ak sa niečo škaredo pokazí nemôžem urobiť rollback). Nepodporuje funkcionálne indexy. Väčšinou chcem správanie unique indexov ako utf8_bin ale zoraďovanie podľa slovenčiny ... Poriadna podpora viewov s indexmi nad viewmi mi tiež chýba. Každá vec ktorú som chcel kedysi použiť bola akosi papierovo tam, ale bola tak neskutočne pokazená, že som sa na celú ich db vykašlal.

    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    5.10.2015 12:00 podlesh | skóre: 38 | Freiburg im Breisgau
    Rozbalit Rozbalit vše Re: Časové rady v django ORM
    Jenom pro úplnost, dvě faktické poznámky o jiných databázích, aby bylo vidět že ne vždy je jinde tráva zelenější
    • v Oracle jsou také DDL mimo transakce
    • v DB2 je délka VARCHAR počet byte, nikoliv znaků (takže při použití UTF se musí validace dělat ne na počet znaků)
    BTW užitečný odkaz: use-the-index-luke.com

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.