Byla vydána verze 2.12.0 QEMU (Wikipedie). Přispělo 204 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn. Řešeny jsou také bezpečnostní chyby Meltdown a Spectre.
Google zveřejnil seznam 1 264 studentů přijatých do letošního Google Summer of Code. Přehled projektů, studentů, 212 organizací a mentorů je k dispozici na stránkách GSoC.
Oracle vydal verzi 1.0 univerzálního virtuálního stroje GraalVM, který umožňuje běh programů napsaných v jazycích založených na JVM, JavaScript, LLVM bitcode a experimentálně Ruby, R a Python.
Julia Evans pomocí svých kreslených obrázků proniká do Linuxu a informačních technologií. Vedle ucelených zinů publikuje také jednotlivé kreslené obrázky (RSS).
Jordi Sanfeliu vydal verzi 1.0.0 svého unixového jádra Fiwix (Wikipedie) určeného také pro výuku operačních systémů. Dle článku na OSNews na něm začal pracovat již před více než dvaceti lety. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT. Stáhnout a vyzkoušet lze živou disketu nebo CD s GNU/Fiwixem.
Byla vydána nová verze 10.7 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Vývojáři GitLabu zdůrazňují Web IDE (YouTube) a SAST (Static Application Security Testing) pro Go a C/C++.
David Revoy, autor open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu, zveřejnil na svém blogu recenzi notebooku Librem 13 od společnosti Purism. Používá jej již sedm měsíců a s ním i jako umělec spokojen. Potřebu francouzské AZERTY klávesnice vyřešil přelepkami. Na displej se podíval kalibrační sondou, barvy vyladil pomocí open source softwaru DisplayCAL, v aplikaci Inkscape nastavil zvětšování na 170 % aby 1 cm v Inkscapu byl 1 cm v reálu. Webovou kameru, mikrofon, Wi-Fi a Bluetooth lze na Librem 13 hardwarově vypnout.
Několik posledních verzí GNOME Shellu obsahuje chybu způsobující memory leak (únik paměti). Viz například videozáznamy verzí 3.26 nebo 3.28. Nalezení chyby #64 a její opravě se věnuje Georges Basile Stavracas Neto v příspěvku na svém blogu [reddit].
V pondělí měl na YouTube online premiéru otevřený krátký 2D film Hero vytvořený v 3D softwaru Blender. Cílem stejnojmenného projektu Hero je vylepšit nástroj Grease Pencil (tužka) v Blenderu 2.8.
Byla vydána verze 4.0 kolekce svobodného softwaru umožňujícího nahrávání, konverzi a streamovaní digitálního zvuku a obrazu FFmpeg (Wikipedie). Přehled novinek v Changelogu (GitHub).
Jestli jsem to správně pochopil , tak jste strašné prase =-o.
Takže vy selectujete několik 100 tisícovích tabulek a použijete jenom 30 řádků? Už jak to slyšim tak se mi ježí chlupy na zádech...
PS. Jaké vnitřní kontroly?
Ptáte se jestli je rozdíl v tom, jestli používat "limit" na vrstvě databáze nebo aplikace, z toho plyne že bez limitu se sellectuje vše, proto se na to ptám...
Ale k věci, tohle nasvědčuje o špatném návrhu aplikace/databáze
Mimochodem, Vasek M. ?ne
když má uživatel desítky různých oprávnění typu může číst/zapisovat ... sloupec ten a ten pouze pokud je ve zbývajících toO jakou aplikaci se jedna (aspon obor)? Zkus to rozepsat trosku podrobneji - desitky ruznych opravneni. Z popisu predpokladam spravne, ze opravneni jsou definovana az na uroven sloupcu? Co v tech sloupcich treba je?
selectnuté sloupce tabulek vypadají nějak takto: zamestnanec_id | jmeno | email | skupina | ... | zar1_hodnota_typ | zar2_hodnota_val | ... | zar3_....Sloupce jsou většinou varchar, občas nějaký int. A ano je to definováno až na úroveň sloupců. Oprávnění mi mohou říci třeba to, že uživatel se jmenem pepa a emailem pepa@mail.cz muze cist hodnotu zar2_hodnota_val, ktera je v rozsahu 50-80 a jejiz nazev je /c(.*)[ax]/ nebo jejiz hodnota je 60-90 a zároveň je uživatel ve skupině skupina.
takze ve vysledku se objevuje zarX_hodnota_typ a zarX_hodnota_val, kde X muze byt 0 az X ? tzn. promenny pocet sloupcu ve vysledku?selectnuté sloupce tabulek vypadají nějak takto: zamestnanec_id | jmeno | email | skupina | ... | zar1_hodnota_typ | zar2_hodnota_val | ... | zar3_....
Sloupce jsou většinou varchar, občas nějaký int. A ano je to definováno až na úroveň sloupců. Oprávnění mi mohou říci třeba to, že uživatel se jmenem pepa a emailem pepa@mail.cz muze cist hodnotu zar2_hodnota_val, ktera je v rozsahu 50-80 a jejiz nazev je /c(.*)[ax]/ nebo jejiz hodnota je 60-90 a zároveň je uživatel ve skupině skupina.Toto opravdu silne zavani spatne navrzenou databazi! Predpokladam, ze neexistuje vazebni tabulka napr. uzivatel_smi_cist_zarizeni ? a dalsi vazebni tabulky realizujici takto prava? Opravdu bych na to sel nejakou rozumnou dekompozici - zkratka podobnou logikou jako se chovaji ruzne ORM. NApriklad v prvnim kroku vytahnout uzivatele, v druhem skupinu, ve tretim vsechny jednotky na ktera ma prava on, na ktere skupina, atd ... Minimalne z toho duvodu, aby ses alespon vyhnul zbytecnemu joinovani. Ve vysledku uz muzes vyselektovat jen ty jednotky na ktere ma pravo (jejich idecka mas z predchozich kroku) a aplikovat na ne pripadne dalsi slozitejsi selekt.
Mimochodem teď jsem zkusil vyselektovat ty hodnoty bez LIMITu a limitovat to až v aplikaci a žádné zpoždění se nekonalo, funguje to krásně rychle, řekl bych že malinko rychleji než s těmi původními právy které byly v podmínce where. Jak je to možné? Mimochodem používám v php PDO a prepared statements, 30x fetchnu řádek a pak prepared statement zahodím.Neni to nacachovane? Kolik je ve vysledku radku? Zalezi co vsechno bylo v te podmince WHERE, od urcite slozitosti dotazu (alespon v MySQL) se vyplati rozdelit jeden slozity dotaza na vice malych.
Neni to nacachovane? Kolik je ve vysledku radku? Zalezi co vsechno bylo v te podmince WHERE, od urcite slozitosti dotazu (alespon v MySQL) se vyplati rozdelit jeden slozity dotaza na vice malych.Nekešované to není, zkoušel jsem vybírat 300 řádku postupně s různými OFFSETy a LIMIT jsem nastavoval na 1000000 a zkoušel jsem to i bez LIMITu. V té době nebylo v podmínce where nic. Předtím když jsem zkoušel ten LIMIT 300 v sql, tak tam byly asi 4 podmínky LIKE.
Např. tabulka: zamestnanec_id | jmeno | email | skupina původní řádek: 1, josef, jose@mail.cz, externiste nový řádek: 1, josef, josef@mail2.com, dohledCo když mi oprávnění závisí na sloupcích email a skupina, které jsou na sobě závislé. To bych pak musel aktualizovat po sloupcích a to by bylo dost zlé. Kdybych měnil 20 sloupců, musel bych pro každý z nich zavolat funkci do db JE_OPRAVNEN(...), přičemž při každém volání této funkce by se znovu musely projít oprávnění. Kdežto když to řeším na úrovni aplikace, tak mi stačí dočasně řádek upravit a jednou prohnat kontrolou oprávnění ještě před tím než to zapíšu do databáze. Pokud nepočítám nějaké "hloubkové" procházení dat, tak už tady je "rozdíl složitosti" n^2 : n, a to nepočítám čas potřebný pro komunikaci s db.
Oprávnění mi mohou říci třeba to, že uživatel se jmenem pepa a emailem pepa@mail.cz muze cist hodnotu zar2_hodnota_val, ktera je v rozsahu 50-80 a jejiz nazev je /c(.*)[ax]/ nebo jejiz hodnota je 60-90 a zároveň je uživatel ve skupině skupina.Tady by pomohlo mít ta oprávnění předpočítaná v separátním sloupci abyste nemusel v každém dotazu vyjadřovat takhle složité podmínky. Předpočítání můžete dělat při insertu nebo třeba periodicky.
Tiskni
Sdílej: