Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Jinými slovy: v porovnání s SQL máte v GraphQL jen prosté sloupečky a (outer) joiny. Žádný WHERE nebo ORDER (natož pak GROUP BY).Jsem si toho vědom. Nemám s tím problém.
ved ti to napisali hore, ze sa to da cez row_number ...S lateral joinem je to primitivníŽel s MySQL má člověk smůlu. Sice tam jsou nějaké náznaky window funkcí, ale mě to nefachalo.
ze je otrava a zbytecnost vytahavat data z relacni databaze pomoci nejakyho DSL, abyste z toho ziskali hash-mapu, ktera v podstate odpovida nativnim strukturam v ruznych NO / NEW SQL databazich.
S lateral joinem je to primitivníŽel s MySQL má člověk smůlu. Sice tam jsou nějaké náznaky window funkcí, ale mě to nefachalo.
Jaka je navratnost takove investice?No přece ten pocit, jdu a mám jabko, ten je prostě k nezaplacení!
Kdo zažil ten chápe, tady jdou všechny finance stranou (viz ceny aktuální generace iphonů)
Zní to jako řešení na hovno - platí, že čím víc toho čtu a držím navíc, tím je to 1. náročnější na zdroje, 2. musím řešit více synchronizace.
Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde
Samozrejme ze to jde, ale dostanes sam sebe do pruseru s udrzbou kodu u kazde nove verze OS. Doporucuji si vyhledat v google par prikladu. Ne ze by to neslo, ale je to takove... no neni to dobry napad.
Preklad: z prikazove radky xcodebuild, nebo swift package manager.
Ide treba AppCode, ale na pozadi stejne pobezi xcodebuild.
app -i name -i surname -i age --style verticalUI: bez storyboardu programovat lze, macos i ios, naopak storyboardy nejsou dobry k nicemu velkymu, srat na ne.
Viz můj následující příspěvek. Špatně jsem to popsal. Nejde o cache dat, ale o cache schematu. Nebo spíše logiky.Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
Nedává mi to smysl. Proč používat cache v aplikaci, když relační databáze mívají vlastní propracované cache? Také mi není jasné, proč by se aplikace měla opakovaně ptát na hodnoty, které už má.
Naopak. Díky deklarativnímu SQL se můžu oprostit od detailu uložení dat. Stejně tak nějak musím u inteligentního ORM psát deklarativně a poněkud obecně.Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.
sum = 0
foreach a = collection_of_a()
if test(a) then
b = collection_of_b(a.b_id)
if test(b) then
sum += b.val
return sum
src.iters.filter(\a -> ...).b.iters.filter(\b -> ...).sum()
Bylo to obecné DSL pro získávání obecných dat z ORM. Ale mělo to svá specifika a určitě i omezení.V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.
Nekešují se data, ale schema. Špatně jsem to popsal. Nejlépe osvětlí ukázka:Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.
I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.
foreach ($users(10) as $user) {
echo $user->title;
foreach ($user->articles(10) as $article) {
echo $article->title;
foreach ($article->discuss(5) as $discuss) {
echo $discuss->title;
}
}
}
$sum = 0
foreach ($base->where(test_a) as $a) {
foreach ($a->where(test_b) as $b) {
$sum += $b->val;
}
}
return $sum;
Pro iOS to asi nepůjde, ale pro macOS se dá GUI vyvíjet bez Xcode a jeho UI buildru, stačí vytvořít instanci NSWindow a v něm požadované prvky.
Nevim jestli ti to pomuze, existuje SnapKit. Uprimne bych to ale bez ui bulder nedelal, do budoucna udrzovat to pak muze byt peklo.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.