SQLite BUG ?: SELECT Alias FROM ( Select Field1 Alias::<T> FROM Table)

[97903]

To API neni pro prime pouziti. Nic Ti v jeho pouziti nebrani, jen se nediv chybejici dokumentaci. Tzv. "low level" je z pohledu FireDAC o vrstu vys (tam uz se sdruzuji podporovane DBMS).

Ale ja nepsal nic o low level API. Tohle muzes udelat i "zvenku". Pred predanim prikazu FireDAC objektu prikaz rozparsujes, poskladas si perzistentni pole, predas upraveny dotaz a ten spustis.

FireDAC spousteny prikaz upravuje jen v pripade pouziti maker, takze neni treba chodit tak hluboko do nitra

[miroB]

Ahoj delfin,
nakoniec som postnul tuto zakladnu temu aj na forum Embarcadero.
https://forums.embarcadero.com/thread.jspa?threadID=269003
Moja angličtina môže byť nezrozumiteľná, ale je tam jasný funkčný príklad.
Ten dávam aj sem.
V skratke: tvrdím, že alias::<T>, OK.
Lenže očakávam od neho len ten typecast výsledku, ale určite nie rozšírený názov poľa.
Predstav si viac vnorených SELECT príkazov. Čo s tým strašným chaosom, ktorý by tak vznikol veľmi rýchlo?
Že to nikoho nezaujíma? Ale malo by. Potom by sa tá celá engina používala omnoho produktívnejšie.
Takto sa to používa málo. A je to ozaj problém.
Hmm, teraz ma napadlo, že keby fungovala poriadne funkcia CAST, tak by som mohol dať normálny Alias a nie ten technokratický
Lenže funkcia CAST sa chová ako všetky funkcie vo FireDAC/SQLite. Že nevracia správny typ, ale len ten základný. Takže v SQLite asi ani nemá moc nejaký význam..

Veď aj FireDAC nakoniec interne priznáva, že meno výsledného poľa v skutočnosti nie je to rozšírené, ale to, čo je pred ::<T>
Mám na mysli Field_x_.FieldName
Tak uvidíme, či tam niekto ponúkne riešenie.

[pf1957]

nakoniec som postnul tuto zakladnu temu aj na forum Embarcadero.

Sice jsou cross posty neeticke, ale ja na tvem miste bych to postnul radeji SO - prece jenom tam to auditorium je asi nejvetsi a autor FireDac pred lety sam diskutovaval...

[miroB]

nakoniec som postnul tuto zakladnu temu aj na forum Embarcadero.

Sice jsou cross posty neeticke, ale ja na tvem miste bych to postnul radeji SO - prece jenom tam to auditorium je asi nejvetsi a autor FireDac pred lety sam diskutovaval...

Dik, skusím aj to asi.

[97907]

Muzu Ti odpovedet tady i na EMBT (i na SO, pokud si jeste vzpomenu na login; dlouho jsem tam nebyl), jestli chces

Je to by design. Datove hinty jsou implementovany jen na urovni vnejsiho SELECT listu.

Ohledne view; SQLite si napamatuje (a pamatovat nebude) definici VIEW jinak nez nejakym naznakem pres nazev sloupce. A pokud jej ulozis s hintem, s hintem se na nej musis v SELECT listu obracet, protoze jde o prikaz spousteny na SQLite engine. FireDAC nijak nedonuti SQLite aby si definici VIEW ulozil separatne jako nazev sloupce a datovy typ ktery ten engine ani nezna (i kdyby znal stejne s tim nic nezmuze). Jak by FireDAC podle Tebe mel pretransformovat prikaz pro vytvoreni VIEW tak aby SQLite pochopil ze jde o nazev a datovy typ? Jinymi slovy (kdyz si odmyslis FireDAC), jak chces na SQLite vytvorit VIEW s takovou definici?

To by byl dotaz na predelani SQLite, ne FireDAC.

[miroB]

Delfin, tak ja neviem, nejak tusim, ze mas pravdu. Ale nechcem sa s tym celkom zmierit, pretoze to jednoducho potrebujem.
Ked veci potrebujem, tak sa moc nestaram, ze by nemali ist. Spravim vsetko pre to, aby isli, aby isli lepsie, tak ako potrebujem. Nech maju nejaky zmysel. Spravidla to rovnako potrebuju aj ostatni. Iba sa nikto neozve.
V tom SQLite/FireDAC je uz tak vela spraveneho a zrazu, bac.
Na jednom promile sa ma zastavit cele kvalitne riesnie?
Tak som to postnul na SO. Znacne som to upravil, takze sa to na prvy pohlad moc nepodoba. Muselo sa to zaobist bez vzoroveho kodu ale nastrkal som tam toho dost. Mozno sa toho niekto uchopi.
Mozno to zmazu, je to jedno. Mam ine starosti nez aby som sa obzeral, ako dopadne hodnotenie:)
Tu je link:
https://stackoverflow.com/questions/47517284/firedac-sqlite-typecast-with-as-fldtype-in-nested-queries-functions-how-t

[97910]

Fajn ze se nevzdavas Jen mam vazne obavu ze toho moc nevyresis. Muzes jeste jit cestou toho parsovani a hinty z vnitrnich SELECT listu u SQL prikazu pred spustenim vyhazet. U definice VIEW asi holt smula; tam by musel SQLite nejako podporovat definici nazvu a datovych typu.

Staci si jen predstavit co se deje na ktere strane. V tomto pripade se prikazy spousti na SQLite engine, a produktem uspesneho spusteni je popis datasetu ze ktereho muze FireDAC pomoci datovych hintu specifikovat pole v kolekci "na prani".

[miroB]

Fajn ze se nevzdavas Jen mam vazne obavu ze toho moc nevyresis. Muzes jeste jit cestou toho parsovani a hinty z vnitrnich SELECT listu u SQL prikazu pred spustenim vyhazet. U definice VIEW asi holt smula; tam by musel SQLite nejako podporovat definici nazvu a datovych typu.

Staci si jen predstavit co se deje na ktere strane. V tomto pripade se prikazy spousti na SQLite engine, a produktem uspesneho spusteni je popis datasetu ze ktereho muze FireDAC pomoci datovych hintu specifikovat pole v kolekci "na prani".

Aha, tak to znamená, že "fld::type" sa musí strčiť celé do SQLite enginy, aby sa zas až pri výstupe dal dešifrovať typ pre prezentáciu dát?
No a mimochdom UDF funkcie nie su tie prišité aj vrátane definície práve do enginy?
A nemôžu teda prenášať žiadnu informáciu, keď sú k engine nejak prilinkované?
Nechce sa mi veriť, že toto je neriešiteľný problém.
Voči tomu, čo je v oboch balíkoch už naprogramované.

[miroB]

To API neni pro prime pouziti. Nic Ti v jeho pouziti nebrani, jen se nediv chybejici dokumentaci. Tzv. "low level" je z pohledu FireDAC o vrstu vys (tam uz se sdruzuji podporovane DBMS).

Ale ja nepsal nic o low level API. Tohle muzes udelat i "zvenku". Pred predanim prikazu FireDAC objektu prikaz rozparsujes, poskladas si perzistentni pole, predas upraveny dotaz a ten spustis.

FireDAC spousteny prikaz upravuje jen v pripade pouziti maker, takze neni treba chodit tak hluboko do nitra

Na ktorom mieste presne v kode mozem povedat, ze nechcem column definition podla FireDAC, ale podla seba.
Ako nizko musim teda ist? Ak vravis., ze nie je uplne nutne low-level.
Niekde som videl aj take odporucene riesnie, ze si pred kazdym SQL vytvoris temp table so svojou definíciou polí a tam nasypeš data zo selectu.
No a ak by som to spojil s low-level, tak som pomaly doma..

[97918]

Na ktorom mieste presne v kode mozem povedat, ze nechcem column definition podla FireDAC, ale podla seba.
Ako nizko musim teda ist? Ak vravis., ze nie je uplne nutne low-level.
Niekde som videl aj take odporucene riesnie, ze si pred kazdym SQL vytvoris temp table so svojou definíciou polí a tam nasypeš data zo selectu.
No a ak by som to spojil s low-level, tak som pomaly doma..

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

[miroB]

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

Ak uvediem konkretne na priklade, tak kedy v ramci tohoto?

Kód: MySQL [Vybrat]

1.   FDQuery1.SQL.Text := 'SELECT * FROM [myView]';                  
2.   FDQuery1.Active   := True;

Pred riadkom 1, 2, alebo az na konci.
Zatial som to nikdy neriesil.
Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

[97922]

Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

Taky ne. Musi to byt pred otevrenim kurzoru (radek 2.). Snad i pred definici prikazu by se dalo (pokud se ta definice se zmenou prikazu nemaze). Muzu zkusit...

[miroB]

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

Ak uvediem konkretne na priklade, tak kedy v ramci tohoto?

Kód: MySQL [Vybrat]

1.   FDQuery1.SQL.Text := 'SELECT * FROM [myView]';                  
2.   FDQuery1.Active   := True;

Pred riadkom 1, 2, alebo az na konci.
Zatial som to nikdy neriesil.
Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

iiha, to bolo jednoduche. Takze sa blizim k rieseniu.
Opravujem opravene
Bolo to jednoduche, ale unahlil som sa so svojim prispevkom, ten som zmazal a davam spravne zenenie kodu:

Kód: Delphi [Vybrat]

1. FDQuery1.SQL.Text := 'SELECT * FROM ( select [id], [datum] AS [myDate::DATE] from [demo] )';
2. FDQuery1.Active   := True;
3. i := FDQuery1.FieldDefs.Count; // 2
4. FDQuery1.FieldDefs.Clear;
5. i := FDQuery1.FieldDefs.Count; // 0
6. FDQuery1.FieldDefs.Add( 'id', ftSmallInt, 0 );
7. FDQuery1.FieldDefs.Add( 'datum', ftDate, 0 );
8. i := FDQuery1.FieldDefs.Count; // 2
9.  

Kod som doplnil do toho, co som publikoval na embarcadero. Takze keby niekto chcel vyskusat. Ma aj cely kod.
Len toto bolo "vylepsene", co je uvedene tuna som teda pozmenil

[miroB]

BUU.......
POZOR. IBA SA TVARI, ze ide. Vytvorim novu definiciu poli, aj vratane typu.
Zda sa, ze prebehne OK. Ale typ sa nepodari zmenit.
Testujem podrobnejsie a nejde to. Prispevok uz neviem zmazat, ale dam opravu, ked budem vediet, ako dalej pokracovat.

Naplnis jen kolekci FieldDefs. Tak jako bys to udelal v design time pres fields editor.

Ak uvediem konkretne na priklade, tak kedy v ramci tohoto?

Kód: MySQL [Vybrat]

1.   FDQuery1.SQL.Text := 'SELECT * FROM [myView]';                  
2.   FDQuery1.Active   := True;

Pred riadkom 1, 2, alebo az na konci.
Zatial som to nikdy neriesil.
Design time pri databazach nepouzivam snad nikdy. Takze to mi tiez moc nehovori.

iiha, to bolo jednoduche. Takze sa blizim k rieseniu.
Opravujem opravene
Bolo to jednoduche, ale unahlil som sa so svojim prispevkom, ten som zmazal a davam spravne zenenie kodu:

Kód: Delphi [Vybrat]

1. FDQuery1.SQL.Text := 'SELECT * FROM ( select [id], [datum] AS [myDate::DATE] from [demo] )';
2. FDQuery1.Active   := True;
3. i := FDQuery1.FieldDefs.Count; // 2
4. FDQuery1.FieldDefs.Clear;
5. i := FDQuery1.FieldDefs.Count; // 0
6. FDQuery1.FieldDefs.Add( 'id', ftSmallInt, 0 );
7. FDQuery1.FieldDefs.Add( 'datum', ftDate, 0 );
8. i := FDQuery1.FieldDefs.Count; // 2
9.  

Kod som doplnil do toho, co som publikoval na embarcadero. Takze keby niekto chcel vyskusat. Ma aj cely kod.
Len toto bolo "vylepsene", co je uvedene tuna som teda pozmenil

[97929]

BUU.......
POZOR. IBA SA TVARI, ze ide. Vytvorim novu definiciu poli, aj vratane typu.
Zda sa, ze prebehne OK. Ale typ sa nepodari zmenit.

Vsak ony se nemaji menit. Od toho jde o definice Jimi proklamujes ze vis jaka je definice sloupcu datasetu. Proto jsem psal ze muzes naparsovat SQL prikaz, z datovych hintu vnejsiho SELECT listu sestavit kolekci definici a datove hinty vnitrnich prikazu odstranit.

No, a pak jsem psal ze ty definice je treba vytvorit pred otevrenim kurzoru (v puvodnim kodu se kurzor otevira na radku 2.); tj. pred nastavenim Active na True (nebo volanim Open).