Native queries (aneb databáze a OOP)

[stud]

Mám dotaz víceméně ze zvědavosti. Líbí se mi koncept native queries: https://en.wikipedia.org/wiki/Native_Queries
Chápu, jak se to používá a v čem jsou výhody. Jak se to ale implementuje (např. v Javě nebo v C++)? C# má LINQ přímo v jazyku, ale např. u Javy nechápu, jak to udělali. Na webu je hodně příkladů použití, ale nic (jsem nenašel) o implementaci.

[Reklama]

[perceptron]

v c# je to v syntaxi jazyka

v jave sa volania metod prekladaju jednoducho na sql za tym ziadna magia neni

aj ked v jave v tejto oblasti vyhralo jpa resp hibernate

v java 8 su pokusy prepojit lambdy a sql: http://www.jinq.org/ opat ziadna magia.

[Radek Miček]

v java 8 su pokusy prepojit lambdy a sql: http://www.jinq.org/ opat ziadna magia.

S tou magií nevím. Zrovna Jinq funguje tak, že provádí abstraktní interpretaci bajtkódu - pro složitý bajtkód to nefunguje.

[Franta <xkucf03/>]

Koukni taky na http://www.jooq.org/ – umožňuje psát typově bezpečné dotazy. Je to někde na půli cesty mezi psaním čistého SQL a ORM.

[zboj]

Koukni taky na http://www.jooq.org/ – umožňuje psát typově bezpečné dotazy. Je to někde na půli cesty mezi psaním čistého SQL a ORM.

Pleteš si (stejně jako perceptron) NQ a SODA.

[Reklama]

[zboj]

Mám dotaz víceméně ze zvědavosti. Líbí se mi koncept native queries: https://en.wikipedia.org/wiki/Native_Queries
Chápu, jak se to používá a v čem jsou výhody. Jak se to ale implementuje (např. v Javě nebo v C++)? C# má LINQ přímo v jazyku, ale např. u Javy nechápu, jak to udělali. Na webu je hodně příkladů použití, ale nic (jsem nenašel) o implementaci.

Je to magie ve všech jazycích (na rozdíl od SODA, což si lidi evidentně pletou s NQ). V Javě bych to psát nechtěl (překládá se bytecode do OQL). Jednodušeji to jde v C++, C++/CLI, C++/CX, Objective-C a úplně nejjednodušeji ve Swiftu (ale pořád musí být člověk borec, aby to napsal rozumně a použitelně). Dá se pak napsat něco jako

Kód [Vybrat] Rozbalit

let objects = database.findObjects({ obj:MyObject in obj.someField <= 1234 })

Na rozdíl od SODA to je čitelnější a přirozenější (vypadá to jako lambda výraz, ale převádí se na OQL nebo něco podobného). Klidně se vsadím, že 95% (to je ještě opatrný odhad, možná i 99%) programátorů by to ale nenapsalo ani v C++, ani v ObjC, ani ve Swiftu - je to hodně advanced. Na druhou stranu hotovou implementaci může použít jednoduše každý a je to mnohem lepší než "string-based query interface" (viz odkazovaný článek).

[Ondrej Nemecek]

Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

[zboj]

Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

S ORM to nemá nic společného. NQ je něco jako

Kód [Vybrat] Rozbalit

Query(obj:MyObject in obj.field >= 1234)

kdežto SODA bude něco jako

Kód [Vybrat] Rozbalit

Query(MyObject.self).whereField("field").geqThan(1234)

z čehož plyne, že NQ je lepší (z hlediska bezpečnosti, resp. kontroly během kompilace). Navíc SODA je ukecaný guláš. Na druhou stranu SODA je lepší než textové OQL v kódu.

Kdo zkusí implementovat NQ v různých jazycích, krásně zjistí, v čem se různé implementace OOP liší - každý jazyk v něčem hapruje, např. C++ nemá introspekci (ale preprocesor to nahradí), Swift nemá implicitní konverzi typů (v dřívější betě měl, ale už je pryč), v Javě se člověk musí hrabat v bajtkódu. Microsoftí C++ (CLI nebo CX) je na tom z tohoto pohledu asi nejlépe, ale zase to je okrajová záležitost.

[Ondrej Nemecek]

Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

Jasně, díky, už jsem se toho taky dovtípil - v NQ se ty podmínky zapisují pomocí java kódu (vezměme jako příklad javu), takže to vypadá, jakoby se podmínka vyhodnocovala přímo v javě (kde se ve skutečnosti vyhodnocuje to je jiná otázka, zřejmě se z bajtkódu vyganeruje sql). Například zde http://www.java-objects-database.com/jodb-general-section/help/native-query.html je příklad, kde se podmínka zapíše jako

Kód [Vybrat] Rozbalit

return pilot.getPoints() > 100 && pilot.getPoints() < 500 ;

V SODA se uvádí název sloupce, takže by tam bylo něco jako

Kód [Vybrat] Rozbalit

Query.from(Pilot.class).where("points > ?", 100).and("points < ?", 500).selectAll();

Jenže třeba Dari http://www.dariframework.org/ překládá textovou SODA-like syntax na predikáty http://www.dariframework.org/javadocs/com/psddev/dari/db/PredicateParser.html Otázka je, zda jde ve výsledku o NQ nebo SODA.

Která vrstva rozhoduje, jestli jde o NQ nebo SODA? Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

A za ORM byste teda považoval jen to, jakým způsobem se zabalí výsledek SQL dotazu do objektů?

[zboj]

Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

Jasně, díky, už jsem se toho taky dovtípil - v NQ se ty podmínky zapisují pomocí java kódu (vezměme jako příklad javu), takže to vypadá, jakoby se podmínka vyhodnocovala přímo v javě (kde se ve skutečnosti vyhodnocuje to je jiná otázka, zřejmě se z bajtkódu vyganeruje sql). Například zde http://www.java-objects-database.com/jodb-general-section/help/native-query.html je příklad, kde se podmínka zapíše jako

Kód [Vybrat] Rozbalit

return pilot.getPoints() > 100 && pilot.getPoints() < 500 ;

V SODA se uvádí název sloupce, takže by tam bylo něco jako

Kód [Vybrat] Rozbalit

Query.from(Pilot.class).where("points > ?", 100).and("points < ?", 500).selectAll();

Jenže třeba Dari http://www.dariframework.org/ překládá textovou SODA-like syntax na predikáty http://www.dariframework.org/javadocs/com/psddev/dari/db/PredicateParser.html Otázka je, zda jde ve výsledku o NQ nebo SODA.

Která vrstva rozhoduje, jestli jde o NQ nebo SODA? Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

A za ORM byste teda považoval jen to, jakým způsobem se zabalí výsledek SQL dotazu do objektů?

"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

[noef]

Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

Ehm, není to přesně to samé? Nebo jde jen o ten bytekód (to nezní moc obecně)?

[zboj]

BTW v ideálním OO jazyce by to šlo přímočaře, jenže takový jazyk neexistuje. Je totiž potřebný přístup k AST. V jazycích s přetěžováním operátorů se to dá většinou nějak napsat, ale je to buď prasárna nebo nedokonalé. Swift by byl v tomto ohledu téměř dokonalý, kdyby měl implicitní konverzi typů, jenže ta by zase haprovala jinde (proto ji odstranili).

[Ondrej Nemecek]

"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

Dobře, jak vznikne z NQ ten SQL?

[zboj]

"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

Dobře, jak vznikne z NQ ten SQL?

OQL, ne SQL. To je právě ta magie. V Javě z bajtkódu, jinak se musí nějak poskládat AST. Když jsem si s tím hrál naposledy v C++, microsoftí překladač zkolaboval a v clangu jsem tak našel bug v linkeru. Swift to v poslední verzi zvládá hezky (operátor se dá přetížit několikrát s různými návratovými hodnotami a automatická inference typu udělá z "x == 100" buď bool nebo predikát podle místa použití - tak má ostatně OOP vypadat), jen ta implicitní konverze chybí.

[Ondrej Nemecek]

Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

Ehm, není to přesně to samé? Nebo jde jen o ten bytekód (to nezní moc obecně)?

Myslel jsem to tak, že pro NQ je potřeba nějaká manipulace s batekódem (po kompilaci) anebo podpora v runtime (která s bajtkódem něco dělá za běhu), kdežto SODA jen jednoduše pospojuje řetězce a hotovo.