Příspěvky

301

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 18. 07. 2021, 15:59:03 »

tudíž za mě to považuji za vyřešené.

Ty vaše příklady jsou krásná ukázka toho, že lidé často píšou pořád v jednom programovacím jazyce, bez ohledu na to, jakou syntaxi zrovna používají. Ten váš příklad je C, nebo Python, nebo jakýkoli imperativní jazyk, akorát napsaný pomocí XSLT syntaxe.

Mýlíš se, jako vždy, ale to nevadí.

302

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 18. 07. 2021, 14:59:08 »

Palety iterují jen na sobě, boxy jen v jednom kole.
Počítá mi to takto:

Kód: [Vybrat]

<Pack>
		<Type>Pallet</Type>
		<ID>11</ID>
		<Sequence>1</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>aaa</Child>
		<Parent>1</Parent>
		<Sequence>2</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>bbb</Child>
		<Parent>1</Parent>
		<Sequence>2</Sequence>
	</Pack>
	<Pack>
		<Type>Pallet</Type>
		<ID>10</ID>
		<Sequence>2</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>ccc</Child>
		<Parent>2</Parent>
		<Sequence>3</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>ddd</Child>
		<Parent>2</Parent>
		<Sequence>3</Sequence>
	</Pack>
	<Pack>
		<Type>Pallet</Type>
		<ID>6</ID>
		<Sequence>3</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>zzz</Child>
		<Parent>3</Parent>
		<Sequence>4</Sequence>
	</Pack>

Předpokládám, že jsi si ověřil, že tam máš správný kód a nedošlo k nějaké chybě při přepisu nebo něco podobného, takže mě zajímá: Co za nástroj to zpracovává? Zkoušel jsem Xalan, zkoušel jsem https://xslttest.appspot.com/, tudíž za mě to považuji za vyřešené.

303

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 18. 07. 2021, 03:01:26 »

....

Díky zkusil jsem, ale Sekvence je počítána špatně.
Cílem je, aby sekvence šla plynule za sebou, bez ohledu na to, zda je to paleta nebo box.
A u boxů pak dosazovat do <Parent> sekvenci jejich palety.

Toto je výsledek:

Kód: [Vybrat]

<?xml version="1.0" encoding="utf-8"?>
<Workbook>
	<Pack>
		<Type>Pallet</Type>
		<ID>11</ID>
		<Sequence>1</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>aaa</Child>
		<Parent>1</Parent>
		<Sequence>2</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>bbb</Child>
		<Parent>1</Parent>
		<Sequence>3</Sequence>
	</Pack>
	<Pack>
		<Type>Pallet</Type>
		<ID>10</ID>
		<Sequence>4</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>ccc</Child>
		<Parent>4</Parent>
		<Sequence>5</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>ddd</Child>
		<Parent>4</Parent>
		<Sequence>6</Sequence>
	</Pack>
	<Pack>
		<Type>Pallet</Type>
		<ID>6</ID>
		<Sequence>7</Sequence>
	</Pack>
	<Pack>
		<Type>Box</Type>
		<Child>zzz</Child>
		<Parent>7</Parent>
		<Sequence>8</Sequence>
	</Pack>
</Workbook>

Tobě to nedělá? Nebo to je špatnej výsledek?

Používám Xalan, ale mělo by to být natolik standardní, že by na tom nemělo záležet.

304

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 18. 07. 2021, 00:15:59 »

Výsledek by měl být Paleta, boxy na ní, Paleta, boxy na ní.

Kód: [Vybrat]

<Workbook>
    <Pack>
	<Type>Pallet<Type>
	<ID>11</ID>
	<Sequence>1</Sequence>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>aaa</ID>
	<Sequence>2</Sequence>
	<Parent>1</Parent>
    </Pack>
	<Type>Box<Type>
	<ID>bbb</ID>
	<Sequence>3</Sequence>
	<Parent>1</Parent>
    </Pack>
	<Pack>
	<Type>Pallet<Type>
	<ID>10</ID>
	<Sequence>4</Sequence>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>ccc</ID>
	<Sequence>5</Sequence>
	<Parent>4</Parent>
    </Pack>
	<Type>Box<Type>
	<ID>ddd</ID>
	<Sequence>6</Sequence>
	<Parent>4</Parent>
    </Pack>
	<Type>Pallet<Type>
	<ID>6</ID>
	<Sequence>7</Sequence>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>zzz</ID>
	<Sequence>8</Sequence>
	<Parent>7</Parent>
    </Pack>
</Workbook>	

Takhle?:

Kód: [Vybrat]

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
		xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
		>

	<xsl:output method="xml" encoding="utf-8" indent="yes"/>

	<xsl:template match="/">
		<Workbook>
			<xsl:call-template name="Pack" />
		</Workbook>
	</xsl:template>


	<xsl:template name="Pack">
		<xsl:for-each select="/ResultsSet/ResultSet[1]/Row">
			<xsl:variable name="ParentIndex" select="position()"/>
			<xsl:variable name="ParentId" select="Parent"/>
			<xsl:for-each select="/ResultsSet/ResultSet[2]/Row[Parent = $ParentId]">
				<xsl:if test="position() = 1">
					<xsl:variable name="ParentSequence" select="$ParentIndex + count(preceding-sibling::Row)"/>
					<Pack>
						<Type>Pallet</Type>
						<ID><xsl:value-of select="$ParentId"/></ID>
						<Sequence><xsl:value-of select="$ParentSequence" /></Sequence>
					</Pack>
					<xsl:for-each select="/ResultsSet/ResultSet[2]/Row[Parent = $ParentId]">
						<Pack>
							<Type>Box</Type>
							<Child><xsl:value-of select="Child"/></Child>
							<Parent><xsl:value-of select="$ParentSequence" /></Parent>
							<Sequence><xsl:value-of select="$ParentIndex + 1 + count(preceding-sibling::Row)" /></Sequence>
						</Pack>
					</xsl:for-each>
				</xsl:if>
			</xsl:for-each>
		</xsl:for-each>
	</xsl:template>

</xsl:stylesheet>

305

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 17. 07. 2021, 22:51:40 »

...

Kód: [Vybrat]

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
		xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
		>

	<xsl:output method="xml" encoding="utf-8" indent="yes"/>

	<xsl:template match="/">
		<Workbook>
			<xsl:call-template name="Pack" />
		</Workbook>
	</xsl:template>


	<xsl:template name="Pack">
		<xsl:for-each select="/ResultsSet/ResultSet[1]/Row">
			<xsl:variable name="ParentId" select="Parent"/>
			<xsl:variable name="ParentIndex" select="position()"/>
			<Pack>
				<Type>Pallet</Type>
				<ID><xsl:value-of select="Parent"/></ID>
				<Sequence><xsl:value-of select="position()" /></Sequence>
			</Pack>
			<xsl:for-each select="/ResultsSet/ResultSet[2]/Row[Parent = $ParentId]">
				<Pack>
					<Type>Box</Type>
					<Child><xsl:value-of select="Child"/></Child>
					<Sequence><xsl:value-of select="position()" /></Sequence>
					<Parent><xsl:value-of select="$ParentIndex" /></Parent>
				</Pack>
			</xsl:for-each>
		</xsl:for-each>
	</xsl:template>

</xsl:stylesheet>

306

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 17. 07. 2021, 22:38:04 »

1) Omlouvám se za nepřesný popis případu, níže to vyjasním lépe.
2) To co chci, dokážu, ale tak, že zpracuji cyklem a XML výstup v dalším payloadu ztransformuju.
3) To stejné bych ale chtěl docílit v rámci jednoho payloadu, pravděpodobně pomocí template jak tady zmiňujete.

V ResultSet[1] mám seznam palet. V ResultSet[2] mám seznam krabic a na jaké paletě leží <Parent>.
Celý problém tkví v tom, že v hlavním xsl:foreach cyklu je ještě vnitřní cyklus a v obouch používám position().
Ve vnitřním cyklu jen přičítám +1 aby sekvenční číslo jednotlivých <Package> iterovalo správně.
Takže vznikne první element Package typu paleta a následujou Package typu box co jsou na ní naloženy. Pak další Package typu paleta a za ním Package typu box co jsou na ní.
Havní problém je v tom, že se počítá pomocí position() v obou cyklech a tím nikdy nevznikne postupné číslování.
Další, co pak budu řešit, je přiřadit všem Package typu Box sekvenční číslo jejich palety/rodiče.

Kód: [Vybrat]

<ResultsSet>
   <ResultSet>
     <Row><Parent>11</Parent></Row>
     <Row><Parent>10</Parent></Row>
     <Row><Parent>6</Parent></Row>
   </ResultSet>
   <ResultSet>
     <Row>
         <Child>aaa</Child>
         <Parent>11</Parent>
     </Row>
     <Row>
         <Child>bbb</Child>
         <Parent>11</Parent>
     </Row>
     <Row>
         <Child>ccc</Child>
         <Parent>10</Parent>
     </Row>
     <Row>
         <Child>ddd</Child>
         <Parent>10</Parent>
     </Row>
     <Row>
         <Child>zzz</Child>
         <Parent>6</Parent>
     </Row>
   </ResultSet>
</ResultsSet>

Kód: [Vybrat]

<xsl:for-each select="/ResultsSet/ResultSet[1]/Row">
    <xsl:variable name="Parent" select="/ResultsSet/ResultSet[1]/Row/Parent"></xsl:variable>
    <Pack>
	<Type>Pallet<Type>
	<ID><xsl:value-of select="Parent"/></ID>
	<Sequence><xsl:value-of select="position()"></Sequence>
    </Pack>
	
    <xsl:for-each select="/ResultsSet/ResultSet[2]/Row[Parent='$Parent']">
    <Pack>
	<Type>Box<Type>
	<ID><xsl:value-of select="Child"></ID>
	<Sequence><xsl:value-of select="position() +1"></Sequence>
	<Parent>sekvenční číslo rodičovské palety</Parent>
    </Pack>
    </xsl:for-each>

Takže výsledek má vypadat takto?

Kód: [Vybrat]

<Workbook>
    <Pack>
	<Type>Pallet<Type>
	<ID>11</ID>
	<Sequence>1</Sequence>
    </Pack>
    <Pack>
	<Type>Pallet<Type>
	<ID>10</ID>
	<Sequence>2</Sequence>
    </Pack>
    <Pack>
	<Type>Pallet<Type>
	<ID>6</ID>
	<Sequence>3</Sequence>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>aaa</ID>
	<Sequence>1</Sequence>
	<Parent>1</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>bbb</ID>
	<Sequence>2</Sequence>
	<Parent>1</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>ccc</ID>
	<Sequence>3</Sequence>
	<Parent>2</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>ddd</ID>
	<Sequence>4</Sequence>
	<Parent>2</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>zzz</ID>
	<Sequence>5</Sequence>
	<Parent>3</Parent>
    </Pack>
</Workbook>

nebo takhle?

Kód: [Vybrat]

<Workbook>
    <Pack>
	<Type>Pallet<Type>
	<ID>11</ID>
	<Sequence>1</Sequence>
    </Pack>
    <Pack>
	<Type>Pallet<Type>
	<ID>10</ID>
	<Sequence>2</Sequence>
    </Pack>
    <Pack>
	<Type>Pallet<Type>
	<ID>6</ID>
	<Sequence>3</Sequence>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>aaa</ID>
	<Sequence>1</Sequence>
	<Parent>1</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>bbb</ID>
	<Sequence>2</Sequence>
	<Parent>1</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>ccc</ID>
	<Sequence>1</Sequence>
	<Parent>2</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>ddd</ID>
	<Sequence>2</Sequence>
	<Parent>2</Parent>
    </Pack>
    <Pack>
	<Type>Box<Type>
	<ID>zzz</ID>
	<Sequence>1</Sequence>
	<Parent>3</Parent>
    </Pack>
</Workbook>

307

Vývoj / Re:XSLT - xpath axes uvnitř cyklu

« kdy: 17. 07. 2021, 17:18:45 »

Měl jsem na mysli vstupní XML. Mám si ho snad vycucat z prstu?

Vstupní struktura je zde k ničemu, protože na ni se jen odkazuju cyklusem. Nebudu sem dávat kompletní vstup(je obrovskej), ale logika je takováto.
Vstupní payload:

Kód: [Vybrat]

<ResultsSet>
   <ResultSet>
     <Row><Parent>11</Parent></Row>
     <Row><Parent>10</Parent></Row>
     <Row><Parent>6</Parent></Row>
   </ResultSet>
   <ResultSet>
     <Row>
         <Child>aaa</Child>
         <Parent>11</Parent>
     </Row>
     <Row>
         <Child>bbb</Child>
         <Parent>11</Parent>
     </Row>
     <Row>
         <Child>ccc</Child>
         <Parent>10</Parent>
     </Row>
     <Row>
         <Child>ddd</Child>
         <Parent>10</Parent>
     </Row>
     <Row>
         <Child>zzz</Child>
         <Parent>6</Parent>
     </Row>
   </ResultSet>
</ResultsSet>

V následujícím payloadu:

Kód: [Vybrat]

<xsl:for-each select="/ResultsSet/ResultSet[1]/Row">
      <xsl:variable name="Round" select="position()"></xsl:variable>
      <Pack>
      <Parent>Pallet</Parent>
      <ID><xsl:value-of select="Parent"/></Parent>
      <xsl:choose>
            <xsl:when test="$Round='1'">
    	         <Number><xsl:value-of select="position()"></xsl:value-of></Number>
    	    </xsl:when>
    	    <xsl:otherwise>
    	         <Number><xsl:value-of select="./ancestor::Pack/Number +1"></xsl:value-of></Number>
    	    </xsl:otherwise>
      </xsl:choose>
</xsl:for-each>

S osama potřebuji pracovat až na nově vznikající xml struktuře uvnitř cyklu. Hodnota v elementu <Number> se bude měnit ještě na základě jiných podmínek, ale do toho nemá smysl zabředávat. Otazka zní, zda se pomocí xpath axes dá ukazovat na strukturu, která je vytvořena v předchozím kole cyklu.

Předpokládejme, že chceš takovýto výstup:

Kód: [Vybrat]

<Workbook>
	<Pack>
		<ID>11</ID>
		<Items>
			<Child>aaa</Child>
			<Child>bbb</Child>
		</Items>
	</Pack>
	<Pack>
		<ID>10</ID>
		<Items>
			<Child>ccc</Child>
			<Child>ddd</Child>
		</Items>
	</Pack>
	<Pack>
		<ID>6</ID>
		<Items>
			<Child>zzz</Child>
		</Items>
	</Pack>
</Workbook>

Takhle by to nešlo?

Kód: [Vybrat]

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
		xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
		>

	<xsl:output method="xml" encoding="utf-8" indent="yes"/>

	<xsl:template match="/">
		<Workbook>
			<xsl:call-template name="Pack" />
		</Workbook>
	</xsl:template>


	<xsl:template name="Pack">
		<xsl:for-each select="/ResultsSet/ResultSet[1]/Row">
			<xsl:variable name="Parent" select="Parent"/>
			<Pack>
				<ID><xsl:value-of select="Parent"/></ID>
				<Items>
					<xsl:for-each select="/ResultsSet/ResultSet[2]/Row[Parent = $Parent]">
						<Child><xsl:value-of select="Child"/></Child>
					</xsl:for-each>
				</Items>
			</Pack>
		</xsl:for-each>
	</xsl:template>
</xsl:stylesheet>

Mám za to, že ve foreach v každé iteraci pracuje vždy s původním zdrojem. Tudíž tak jak si to představuješ to nejde. (Ani to není dobrý nápad, mění se ti data pod rukama.)

Takže mě napadají dva způsoby:
1/ buď nepracovat s lokálním nodem, ale jít o úroveň víš, a zpracovat si v ciklu najednou všechno co potřebuješ (viz má ukázka)
2/ nebo nejdřív zpracovat část v celém ciklu, a pak nad výsledkem projet nové kolo s další logikou - volat šablonu nad výsledkem jiné šablony (to žel neumím).

308

Odkladiště / Re:Čeština a IT výrazy

« kdy: 15. 07. 2021, 15:26:14 »

Právě jsem vytvořil commit (sic): "Vytvoří pro Fondy továrny, aby se dali dát do DIContaineru."
Všimněte si angličtiny s českou gramatikou použité za účelem vtípku.

309

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 14:08:33 »

Ale pracuje s tím i programátor,

Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.

Já myslím, že jsme u jádra pudla.
Zkusíme to na malých a extrémních příkladech.

Zkuste mi prosím popsat, jak by ORM mohlo vědět např. kdy se vyplatí z DB vytáhnout více dat hromadně dopředu, když v daný okamžik má požadavek třeba jen na jeden záznam - přičemž programátor s určitou přesností ví, že bude potřebovat vybranou sadu záznamů? ORM se může rozhodnout mezi dvěma extrémy - vzít a doručit jednu položku (a pokud to bude ve smyčcce, tak vygeneruje spoustu dotazů), nebo natáhnout do aplikace všechny (třeba i spoustu zbytečných). ORM není schopno rozhodnout "nic mezi", zatímco programátor s určitým úspěchem ano.

Nebo, někdy se vyplatí k záznamům rovnou dotáhnout (joinem) navázané informace. Aplikace je může potřebovat až někdy později za běhu, ale ví se, že je potřebovat bude (v některých případech). ORM se zase může leda rozhodnout, že je dotáhne ad hoc po jednom (spousta dotazů ve smyčce), ad hoc hromadně (pak join provádí aplikace svojí logikou), nebo dopředu (tj. bude je tahat i v případech, kdy nebudou potřeba). Opět, toto může ovlivnit jedině programátor tím, že to tomu ORM dá nějak na vědomí.

Oblíbená strategie, která se už běžně používá, a tedy není to žádné scifi je, že se provede první kolo, kde se použijou úplně naivní a neefektivní dotazy, a na základě toho se odvodí, jak má vypadat optimální.

Máš tam něco těžšího? :-)

Opravdu, ta představa, že programátor ví víc, než je schopen zjistit stroj je mylná (čest výjimkám).
Normální programátor jde, a koukne se do databáze. To ORM může udělat taky. Normální programátor jde, a vytvoří nějaký požadavek na data. To ví ORM taky.
Co by ORM nemohla vědět?

To jsou dva úplně triviální příklady, kdy se ORM nemůže rozhodnout za programátora. Ano, programátor může ORM nahintovat, aby se zachovalo tak, jak si představuje. Tím se ale ztrácí kus univerzálnosti ORM řešení, a navíc ten programátor stejně musí znát, co je v pozadí. Bez toho nemůže vědět, jak hintovat.

Toto jsem měl za to, že už jsme si vyříkali, a že jsem se vyjadřoval dostatečně expresivně: motivací ORM, určitě ne primární, není schovat DB. Já jsem pro hinty, a jsem pro to, aby mi ORM ukazovalo, jaké SQL vytváří, a mít možnost to ovlivnit. OK? Můžeme se k tomu už nevracet prosím?

To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.

V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.

To máš samozřejmě pravdu. A to nikdo nerozporuje. A tudíž v tom nevidím ten principielní problém, který by ORM nějak zvláště hendikepovalo.

Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.

Toto vypadá na jedno ze zásadních nepochopení. Mé tvrzení, že ORM dokáže vyčíst to samé co vývojář nijak nesouvisí se skutečností, že Databáze je model, který popisuje zjednodušenou realitu. (Nehledě na to, že i tam je spoustu "ale".)

310

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 07. 07. 2021, 00:20:27 »

Ale pracuje s tím i programátor,

Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.

Ani s tou milisekundou sem, milisekundou tam podle mě nemáte pravdu. Obecně ORM systémy generují vyšší počet dotazů. Když máte 50 dotazů na úkon, a na každém dotazu ztratíte 5 ms a k systému přistupuje 100 lidí, vytvoříte si lap 25 sekund. V lepším případě se to projeví jen tím, že každý uživatel čeká o čtvrt sekundy déle, což bývá přijatelné. V horším případě čekají transakce za sebou (kvůli ACID) a lap na uživatel je mnohem vyšší.

Já mluvil o milisekundách spálených na mapování výsledku dotazu na objektovou reprezentaci. V žádném případě na tom, že by ORM mělo posílat horší dotazy než by napsal vývojář.

Zbytek je opět sklouznutí ke steskům nad nekvalitou ORM.

Podle mě v úvahách směřujete spíš od ORM k nějaké objektové databázi,

Určitě ne.

Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?

Ty, které může lépe získat stroj: tzn. statistiky atd...., ORM získat za rozumný čas nemůže, protože prostě na ně "nevidí". Nemá ty data, ty má DB. Proto je tato otázka chybně položená. Není problém v "STROJ versus VÝVOJÁŘ", problém je v tom, jaké možnosti má stroj na úrovni ORM vrstvy - a že kdybys chtěl ty problémy překonat, tak bys musel do té ORM vrstvy nutně zabudovat i celou databázi.
No a pak jsou informace, které prostě stroj (přinejmenším v dnešním stavu AI) získat prostě nemůže. To, co si od takového ORM představuješ je defakto schopnost programovat, a ta jestli je principiálně vůbec možná (asi jo), tak je úplně někde jinde, než co dneska umíme.
Jak píše Pavel: i SQL databáze, která řeší jednoduché a matematicky snadno popsatelné problémy relační algebry, řeší u každého přístupu jen pár vhodných strategií - a i tam občas selhává. A ty bys chtěl vlastně po ORM něco, co by umělo ne volit jednu strategii z pár "napevno zadrátovaných", ale které by umělo algoritmizaci. Jasně - teroreticky to asi možný je. Ale až to budeme umět, tak budeme umět konstruovat androidy - a programátoři přijdou o práci.... :-)

To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.

311

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 02. 07. 2021, 00:31:01 »

Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.

Možná se nesrozumitelně vyjadřuju, beru. Pokusím se tedy shrnout:

Principiální problém je v tom, že ORM je vrstva nad databází. Očekává se od ní trochu něco jiného než od té databáze.

Pokud bychom přijali, že ideální ORM bude 100% efektivní abstrakce nad databází, v podstatě pak už by databáze nebyla potřeba. Do ORM by se doimplementovaly storage operace a bylo by hotovo.

To je zajímavá úvaha, ale nevidím v ní potenciál. Já nemám problém s existencí db. Mě relační databáze maximálně vyhovují. Já chci na nich stavět. Podle mě to, že ORM je vrstva nad databází je cajk - jasně, nějakým mapováním z ORM do SQL se ztratí nějaká ta setinka (sic!), ale furt lepší, než reimplementovat ty mraky práce odvedených nad databázemi. Nehledě k tomu, že relační algebra je ideální (technologickej i mentální) základ.
Kdepak. Toto nechme být, tak je to správně.

ORM - jakožto pojem - má smysl jen právě proto, že nepřívětivé vlastnosti databáze mapuje do přívětivých objektových operací ve vyšším programovacím jazyce.

Přesně tak.

Toto nelze vyřešit jinak, než kompromisem. Tedy ztráta pramenící z principu, nikoliv z implementace.

Tuto příčinnost zde nepozoruji.

Pavel trefně zmínil absenci statistik (které samy o sobě nedávají 100% odraz skutečnosti). Taky to, že co má databáze při ruce s minimální režií, ORM může získat jen za cenu poměrně vysoké režie (síťová, a další mezivrstvy). Tedy další ztráta pramenící z principu a ne z implementace.

Ve skutečnosti to není ani pravda, ani směrodatné.
Pokud mají databáze statistiky, tak ať je mají. Já jim je přece nechci brát.
ORM tý databáze do ničeho nekecá. Jen ať dělá co nejlepšího umí.
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.
Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?

A pak je tu ten třetí důvod, o kterém můžeme diskutovat, jestli je principiální, nebo implementační. To je volba strategie programátorem. Já ji považuji za principiální. U složitých úloh by se jistě dalo uvažovat o tom, že budoucí optimalizátory budou rychlejší a efektivnější. Jenže pořád tu zůstává velká řada triviálních úloh, u kterých může programátor strategii přímo určit a lze ji považovat za optimální. Tedy, můžeme diskutovat o tom, že by v budoucnu mohlo ORM (kdyby mělo statistiky a mohlo vytvářet hinty), mohlo být efektivnější ve složitých úlohách, než ploché SQL, protože ORM má o struktuře dat trochu jiné, a v určitém ohledu lepší informace. Stejný mechanismus by však zdržoval u triviálních úloh, u kterých by programátor stejně dál preferoval sám určit a vysvětlit postup vykonání. Tedy, ručnímu zásahu by se nedalo vyhnout, pokud bychom hledali výkon.

Výborně. Toto mi dává smysl.
Podle mého názoru, ORM je k tomu, abychom pracovali s nějakými daty nějakým jiným, snad lepším, způsobem. Tak, jak jsi to pěkně popsal o pár odstavců výše. A hlavně aby usnadnilo ruční práci co se mapování týče. Já vůbec nemám problém s tím, aby vývojář tomu ORM řekl, že v tomto a v tomto případě má zvolit jinou strategii. Ve skutečnosti si myslím, že schopnost ORM ukázat, jaký SQL nakonec do db posílá považuju za zcela nutnou funkci. Stejně jako možnost do toho ORMku kecat.
Zároveň si myslím, že kecat mu do toho bude muset jen v několika málo případech.

Možná by se to dalo popsat tak, že v kanceláři si v nějakém budoucím fantastickém ORM naklikají najaký datový model (samozřejmě blbě), ORM z toho syncne změny do databáze a vesele ukládá. Firma funguje, následně narůstají data, databáze se zadejchává, zavolají si Odborníka. Ten zkontroluje datovej model, upraví. Pak zkontroluje statistiky dotazů, a zhodnotí, že na tomto a tomto místě ORMko zvolilo nevhodnou strategii, a změní to.

Nevidím zde prostor pro optimalizaci v podobě constraintů v databázi, protože buď je ORM blbé, a programátor to tam teda doplní ručně a ORM mu nebrání; nebo je ORM schopné, a ví, že ten contsraint může vložit do databáze a udělá to.

312

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 22:19:22 »

Co je překážkou? To už jsem psal. Že struktura dat, tabulí, indexů a dotazů neexistuje jen jediná možná. Existuje mnoho způsobů, jak se dobrat téhož, a liší se složitostí zápisu dotazu (v případě automaticky generováného dotazu nás to netrápí), liší se náročností pro získání dat a liší se náročností pro zápis dat. ORM nedokáže rozhodnout, kterou strategii preferujete. Neví, jestli potřebujete rychle zapisovat a pomalu číst, nebo pomalu zapisovat a rychle číst. Nebo jestli něco mezi. Netuší, jestli bude výhodnější parciální index, ale rychlejší ve většině případů, nebo plný index, rychlý, ale o něco pomalejší v průměrném případě. Neví, jestli Vám jde o celkovou rychlost, nebo o zminimalizování locků...

To vše je na člověku - ne protože by to technologie nechtěla umět, ale protože člověk musí zvolit strategii pro daný projekt. Každá má svá pro a proti.

Tuto myšlenku jsme už tu o pár stránek dříve probírali, včetně mých námitek na ně. Tudíž jen zopakuji: nesouhlasím. Nevidím důvod, proč by to ORM nemělo umět, proč by to neměl zvládnout lépe jak člověk. Z tvého popisuj tento závěr nevyplývá.

Nevím, jestli jste někdy tyto věci řešil - pokud se soustředíte na MySQL, musí to být dost vzdálené si to představit, protože tam opravdu často existuje jen jedna jediná "správná" cesta a všechny ostatní jsou úplně tragické.

Mám pár zkušeností s různými ORM. Mám nějaké zkušenosti s MySQL, Sqlite, PostgreSQL, MSSQL - stačí? A záleží na tom?
Já tě nevnímám jako autoritu, tudy cesta nevede. Tudíž dokavad neuvedeš důvod, proč by to jít nemělo, tak se nepohneme :-) (Jako důvod si představuji něco, na co ti řeknu: "jó, tak to nevím jak by se dalo řešit". Zatím jsem na všechny tvé nepřekonatelné problémy našel snadné řešení a napsal ti ho.)

Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.

Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.

Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev). Zvlášt u extrémně rychlých dotazů (dotazy, které vrací, modifikují pár řádků nad PK), je tato režie hodně vysoká. A v podstatě pak hrdlem je síť a pálíte výkon konverzí dat a realizací komunikace. Můžete si pomoct aplikační cache. Pokud ale máte víc dat, tak se nevejdete do RAM na aplikáči, a a musíte implementovat ACID nad ACIDem, což zase zvyšuje komplexitu nástroje. Implementace distribuované transakční cache je dost komplikovaná záležitost. Zvyšuje se výkon CPU, zvyšují se přenosové rychlosti, IOPS SSD jsou někde úplně jinde, ale na druhou stranu, roste objem dat, klesá trpělivost uživatelů (nikdo nechce čekat na výsledek minuty), a klesají znalosti programátorů (mění se znalosti programátorů - znají ORM, patterny, buildovací prostředí, a virtualizaci), ale neznají základy toho jak fungují databáze (což dřív také nebyla žádná sláva, ale teď to mají k databázím dál). Tudíž si myslím, že posledních 15 let, jsou u větších projektů stejné problémy (i přes brutální nárůst výkonu).

Další problém ORM je odtržení statistik. Sice mohou mít datový model (a mají), ale nemají statistiky, jak data ve skutečnosti vypadají. V ideálním případě by možná tuto znalost nepotřebovali, kdyby existoval ideální optimalizátor dotazů. Už jednoduchá úloha je docela komplikovaná - rozhodnout, jestli si inicializovat cache blokově (napřed si stáhnu potřebná data) nebo iteračně. Pokud budete mít statistiky na aplikáči, tak duplikujete funkcionalitu db, a navíc asi statistiky budete mít jen z cache (nikoliv ze všech dat). Co vím, tak většina ORM statistiky o datech nemá, proto dynamicky nedokáže měnit strategie zpracování dat (nedokáže se přizpůsobit datům). Relační SQL databáze se o to snaží - máte 3 typy JOINů, máte seq scan, index scan - a optimalizátor hledá způsob, jak co nejrychleji přenést data z disku a jak přitom spotřebovat co nejméně paměti.

SQL ale optimalizuje pouze jeden dotaz - už neoptimalizuje sekvenci příkazů. Tam se předpokládá invence programátora. Někdy se vám vyplatí načíst data do RAM aplikáče, a pak nad touto RAM dělat komplikovanější operace. Jindy iterujete po řádcích, jindy agregujete, a gró výpočtu udělá databáze a na aplikáč se posílá jen výsledek. Optimální strategii volí programátor se znalostí dat, a znalostí procesu - ví k čemu data bude používat, a kde je potřebuje.

To co popisuješ není principielní problém ORM. To jsou reálné problémy aktuálních implementací.

Pro příklad hned první věta:

Principiální problém je samozřejmě s výkonem. Tím, že ORM neběží na databázovém serveru, ale na aplikačním, tak máte výrazně větší režii při přístupu k datům (režie sítě, režie protokolu, různých vrstev).

Tohle prostě není pravda. ORM nemá principielní důvod aby měl problém s výkonem. Je to mapper. Ty to popisuješ, jako kdyby si načetl všechny data z databáze k sobě a pak přes foreach to filtroval. Bez ohledu na to, že to některé případi takhle dělají, není to principielní problém.

Já se opravdu nechci bavit o tom, že aktuální ORM implementace mají velké problémy. Já se zajímám o prinicipielní problémy.

313

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 21:09:17 »

Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.

Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.

Ta principiální potíž je v tom, že RDBMS jsou výkonné právě a tehdy, kdy jsou správně nastavené tabule, constrainty, klíče, vzdálené klíče, indexy, ..., a především, když je možné maximum rozhodovacích mechanismů přenést do DB. Interné optimalizátor dotazu se pak těchto informací může chytit a snažit se je využít k vymyšlení nejlepšího postupu pro získání / zápis dat.

Tedy např. když vím, že chci přebarvit všechna auta na červenou, vyjma zelených aut vyrobených v roce 2009, pak potřebuju, aby databáze měla takovou strukturu, aby se k diskriminantům dostala rychle. Musí umět rychle vyhodnotit, jestli nejdřív vybere auta vyrobená <> 2009 a pak s barvou <> zelenou, nebo jestli bude rychlejší opačný postup. Nebo jestli bude nejrychlejší projít všechna auta po sobě, a těch pár, které jsou zelené a vyrobené v 2009 přeskočit (tj. indexy, statistiky, složené indexy, ...).

Můžete mít také auta, u kterých nevíte rok výroby nebo nevíte barvu. ORM za Vás nerozhodne, jestli může (má) použít inner nebo outer join. V prostém případě to nebude mít na výkon velký vliv, ale pokud půjde o složený dotaz se subselecty, bude inner/outer hrát roli v tom, co dokáže optimalizátor ze subselectu vyčlenit nad něj, a co ne.

O tom, jak dotaz realizovat, musí přemýšlet i ten, kdo pracuje přímo v SQL, a nezřídka se stává, že váhá. Zejména, když sestavujete view, tak očekáváte, že bude použito v dalším složeném dotazu. Když view navrhnete špatně, tak může dávat při prostém selectu data rychle, ale může být pro optimalizátor už dále neoptimalizovatelné v dalších složených dotazech. Někdy se vyplatí, pokud víte, co se s tím bude dál dít, napsat view složitěji, ale optimalizovatelněji.

Toto všechno neumí vyřešit RDBMS, a programátor v SQL se s tím taky zapotí. Proto tvrdím, že není reálné očekávat, že ORM by i někdy v budoucnu toto uměly.

Dál mě k tomu přesvědčení vede i to, že optimalizace se musí provádět co nejblíž k datům. RDBMS jsou výkonné jen a právě díky tomu. Dovedu si představit ORM, které by nějakou svojí inteligencí přenášelo nadefinované objekty do dobře vytvořených SQL definic. Jenže to to ORM nebude schopné vymyslet samo, musí to vyčíst z definic poskytnutých programátorem. Tyto definice v rámci ORM by tedy musely být na tolik přesné, aby je šlo 1:1 přenést do DB. Pokud by ty definice měly být na tolik přesné - pak už ORM nebude šetřit práci, pouze bude jinou mluvou definovat totéž.

Mám takový pocit, že hledáte potvrzení, že nějaká ORM mechanika dokáže vymyslet to, co nikdo za desítky let nevymyslel ani v rámci RDBMS.

Tomu co popisuješ dobře rozumím. Čemu nerozumím je, čím podkládáš svá tvrzení, že by to nemělo jít? To v tom textu schází.

Uvedu příklad: V MySQL je taková vlastnost, že v praxi moc nejde použít view, protože implementace v MySQL jej nedokáže optimalizovat a v mnoha případech to degraduje na fullscan. Teď neřešme nakolik je můj popis problému přesný.

Vysvětli mi prosím, máš-li chuť, proč by tuto informaci o tomto zrádném chování nemohlo vědět ORM (ve svém engine pro MySQL), a zohledňovat to při vytváření dotazů? Proč by to musel, principielně umět vývojář. Proč by tato znalost této vlastnosti bylo mnohem náročnější "naučit" ORM, než to učit vývojáře?

A naopak, PostgreSQL umí velice dobře view, a rules, a Sqlite a MySQL od verze (už si nepamatuju) umí window. Etc, etc.,

314

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 20:11:45 »

V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.

Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.

Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.

Nebude zázračný ale bude více než dostatečný. Stejně, jako ručně optimalizovaný kód v asembleru bude vždy lepší jak to co vymyslí kompilátor. Je to stejná písnička (btw, to jsem už taky psal, také se opakuji).

Ok, to už je věc názoru. Potkal jsem už řádku projektů, kde po zvětšení datové nálože a zvýšení přístupů, vylétly požadavky na výkon tak moc, že už se to nijak škálovat nedalo. Pomohl jedině přepis a aspoň důležité části šly mimo ORM (čímž vznikl paskvil, ale aspoň se vyřešil problém).

Jasné, pro malý shopík na webu, kam přijde 50 objednávek za den, bude ORM stačit na věky věkův.

Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.

Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.

315

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 01. 07. 2021, 20:02:10 »

V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.

Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.

Rozumím. A i na to jsem reagoval. I když jdete "pod kapotu" v rámci ORM, výsledek nebude zázračný (důvody jsem psal, nebudu se opakovat). Nikdy to nebude mít šanci využít plný výkon.

Nebude zázračný ale bude více než dostatečný. Stejně, jako ručně optimalizovaný kód v asembleru bude vždy lepší jak to co vymyslí kompilátor. Je to stejná písnička (btw, to jsem už taky psal, také se opakuji).