[Gfoss] sqlite - row number

Ciao a tutti,

qualcuno sa dirmi se esiste in sqlite una funzione simile alla row
number, che mi restituisca un progressivo pari al numero di linea
all'interno di una vista.
Googlando ho trovato qualche cosa che simula il comportamento mediante
una query come questa:

select id, value, (select count(*) from tbl b where a.id >= b.id) as cnt
from tbl a

il problema è che non riesco ad adattarla alle mie esigenze perché la
vista di partenza è già complessa di suo. Esistono altre soluzioni ?

grazie in anticipo
Luca

Ci sarebbe il ROWID.

E’ un attributo hidden che sqlite aggiunge sempre sistematicamente a ogni tabella che viene creata.

Ma è a livello di tabella, non so’ se la sua visibilita’ si espande fino alla vista.

Nelle viste spaziali si è obbligati a definirlo e quindi li sicuramente ci sara’, in quelle alfanumeriche non saprei.

Un potenziale problema per il futuro è che a partire dalla 3…8.2 hanno avuto la bellissima pensata di rendere tale attributo facoltativo (sigh) e uindi in seguito non sar’a piu’ vero.

La 3.8.2 è uscita da circa una settimana.

Perche’ ovviamente pensano che un utente che lavora con un DB sappia sempre quello che fa’.

Hanno messo il rowid a dfault e pero’ se un utente vuole lo potra’ rimuovere.

Sono pronto a scomettere che qualche furbacchione che lo rimuove perche’ cosi’ risparmia qualche byte

salta subito fuori.

Andrea.

···

Il giorno 11 dicembre 2013 16:47, Luca Lanteri <mescal72@gmail.com> ha scritto:

Ciao a tutti,

qualcuno sa dirmi se esiste in sqlite una funzione simile alla row
number, che mi restituisca un progressivo pari al numero di linea
all’interno di una vista.
Googlando ho trovato qualche cosa che simula il comportamento mediante
una query come questa:

select id, value, (select count(*) from tbl b where a.id >= b.id) as cnt
from tbl a

il problema è che non riesco ad adattarla alle mie esigenze perché la
vista di partenza è già complessa di suo. Esistono altre soluzioni ?

grazie in anticipo
Luca


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
666 iscritti al 22.7.2013

Andrea Peri
. . . . . . . . .
qwerty àèìòù

On Wed, 11 Dec 2013 16:56:20 +0100, Andrea Peri wrote:

Ci sarebbe il ROWID.
E' un attributo hidden che sqlite aggiunge sempre sistematicamente a
ogni tabella che viene creata.

Ma è a livello di tabella, non so' se la sua visibilita' si espande
fino alla vista.

dov'e' il problema ?
qualsiasi tavola (vedi sotto per l'eccezione alla regola) ha sempre
una propria colonna "fantasma" di nome ROWID, che e' semplicemente
un alias name ma che sintatticamente funziona esattamente come
qualsiasi altro nome-colonna.

ergo, per rendere visibile il ROWID do una tavola dentro ad una
qualsiasi VIEW basta fare semplicemente qualcosa come:

CREATE VIEW armageddon AS
SELECT a.ROWID AS rowid_tavola1, ... altre colonne ...
FROM tavola1 AS a, tavola2 AS b
WHERE ... qualche clausola ...;

Un potenziale problema per il futuro è che a partire dalla 3..8.2
hanno avuto la bellissima pensata di rendere tale attributo
facoltativo (sigh) e uindi in seguito non sar'a piu' vero.

La 3.8.2 è uscita da circa una settimana.

per l'appunto: l'eccezione alla regola di cui sopra.

per quello che ho potuto verificare fino ad ora si sono
completamente scordati di aggiungere qualsiasi tipo di
supporto lato meta-info / catalogo.

ergo, una volta che la tavola e' stata creata con questa
stravagante nuova opzione WITHOUT ROWID diventa oltretutto
molto rognoso capire in modo predittivo se il ROWID c'e'
realmente oppure no.

sfortunatamente il meta-catalogo "sqlite3_master" non
fornisce nessuna informazione in proposito, e parrebbe
proprio che non ci sia neppure nessuna PRAGMA che
consente di interrogare questa proprieta'.

l'unico approccio possibile pare quello di andarsi direttamente
a verificare lo statement CREATE TABLE iniziale, in questo modo:

SELECT * FROM sqlite_master
WHERE sql LIKE '%WITHOUT ROWID%';

ma pare una soluzione decisamente fragile e molto poco convincente.

ciao Sandro

Ciao Andrea,

grazie mille, grazie al tuo suggerimento ci sono riuscito !
Mi rimane solo un ultimo scoglio che è dovuto alla mia poca
dimestichezza con spatialite.
la mia vista genera la colonna geometria utilizzando makepoint (x,y)
Per rendere la vista geometrica, se ho capito bene, devo inserirla in
VIEWS_GEOMETRY_COLUMNS con
INSERT INTO VIEWS_GEOMETRY_COLUMNS VALUES ('simboli', 'geom',
'gid','simboli',32632,0);

e fin qui tutto bene.
Però quando lancio

SELECT RecoverGeometryColumn('simboli', 'geom', 32632, 'POINT', '2');

mi restituisce false, come se non riconoscesse la colonna geom. Infati
Qgis la vede come una tavola non geometrica.

Dove sto sbagliando ?

grazie mille
Luca

Il 11 dicembre 2013 16:56, Andrea Peri <aperi2007@gmail.com> ha scritto:

Ci sarebbe il ROWID.
E' un attributo hidden che sqlite aggiunge sempre sistematicamente a ogni
tabella che viene creata.

Ma è a livello di tabella, non so' se la sua visibilita' si espande fino
alla vista.
Nelle viste spaziali si è obbligati a definirlo e quindi li sicuramente ci
sara', in quelle alfanumeriche non saprei.

Un potenziale problema per il futuro è che a partire dalla 3..8.2 hanno
avuto la bellissima pensata di rendere tale attributo facoltativo (sigh) e
uindi in seguito non sar'a piu' vero.
La 3.8.2 è uscita da circa una settimana.

Perche' ovviamente pensano che un utente che lavora con un DB sappia sempre
quello che fa'.

Hanno messo il rowid a dfault e pero' se un utente vuole lo potra'
rimuovere.
Sono pronto a scomettere che qualche furbacchione che lo rimuove perche'
cosi' risparmia qualche byte
salta subito fuori.

Andrea.

Il giorno 11 dicembre 2013 16:47, Luca Lanteri <mescal72@gmail.com> ha
scritto:

Ciao a tutti,

qualcuno sa dirmi se esiste in sqlite una funzione simile alla row
number, che mi restituisca un progressivo pari al numero di linea
all'interno di una vista.
Googlando ho trovato qualche cosa che simula il comportamento mediante
una query come questa:

select id, value, (select count(*) from tbl b where a.id >= b.id) as cnt
from tbl a

il problema è che non riesco ad adattarla alle mie esigenze perché la
vista di partenza è già complessa di suo. Esistono altre soluzioni ?

grazie in anticipo
Luca
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On Wed, 11 Dec 2013 18:03:15 +0100, Luca Lanteri wrote:

la mia vista genera la colonna geometria utilizzando makepoint (x,y)

Dove sto sbagliando ?

molto semplice: le Spatial Views di Spatialite supportano
*esclusivamente* le geometrie pescate direttamente tal quali
e senza nessuna rielaborazione da una colonna geometrica gia'
esistente e canonicamente registrata in "geometry_columns"

ergo: la tua geometria generata "al volo" dalla MakePoint
non potra' mai funzionare in una spatial view, semplicemente
perche' non e' possibile mapparla direttamente su nessuna
colonna geometrica definita in "geometry_columns"

hint: piuttosto "materializza" la tua view, creandoti una
tavola di tipo normale che abbia una geometria regolarmente
registrata in "geometry_columns".

ciao Sandro

Ecco l'inghippo.!
Però a me serviva proprio generare la geometria al volo. Forse l'unica
soluzione a questo punto è rigenerare la tavola ad ogni update o
insert con un trigger. O no ?

Il 11 dicembre 2013 18:13, <a.furieri@lqt.it> ha scritto:

On Wed, 11 Dec 2013 18:03:15 +0100, Luca Lanteri wrote:

la mia vista genera la colonna geometria utilizzando makepoint (x,y)

Dove sto sbagliando ?

molto semplice: le Spatial Views di Spatialite supportano
*esclusivamente* le geometrie pescate direttamente tal quali
e senza nessuna rielaborazione da una colonna geometrica gia'
esistente e canonicamente registrata in "geometry_columns"

ergo: la tua geometria generata "al volo" dalla MakePoint
non potra' mai funzionare in una spatial view, semplicemente
perche' non e' possibile mapparla direttamente su nessuna
colonna geometrica definita in "geometry_columns"

hint: piuttosto "materializza" la tua view, creandoti una
tavola di tipo normale che abbia una geometria regolarmente
registrata in "geometry_columns".

ciao Sandro

_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013

On Wed, 11 Dec 2013 18:16:06 +0100, Luca Lanteri wrote:

Ecco l'inghippo.!
Però a me serviva proprio generare la geometria al volo. Forse l'unica
soluzione a questo punto è rigenerare la tavola ad ogni update o
insert con un trigger. O no ?

questa di usare un trigger mi pare un'ottima idea; per inciso,
l'implementazione dei Triggers di SQLite e' veramente eccellente,
ed anche notevolmente efficiente (=veloce)
ti puoi sbizzarrire a piacer tuo facendoci cose veramente
pazzesche: certo, e' sicuramente richiesta una buona familiarita'
con SQL e Spatial SQL, non sono esattamente il top dell'user
friendly ... in compenso offrono una potenza quasi infinita :wink:

ciao Sandro

Che dire,

Grande Sandro e grande Andrea, grazie a entrambe ! Un supporto così
può uscire solo dalla lista di GFOSS !

Materializzando la tavola funziona tutto, ora provo con i trigger. Ho
già provato a fare qualche altro trigger con spatilite e fino ad ora
non ho avuto grossi problemi. Nel caso vi scoccerò di nuovo.

a presto
Luca

Il 11 dicembre 2013 18:21, <a.furieri@lqt.it> ha scritto:

On Wed, 11 Dec 2013 18:16:06 +0100, Luca Lanteri wrote:

Ecco l'inghippo.!
Però a me serviva proprio generare la geometria al volo. Forse l'unica
soluzione a questo punto è rigenerare la tavola ad ogni update o
insert con un trigger. O no ?

questa di usare un trigger mi pare un'ottima idea; per inciso,
l'implementazione dei Triggers di SQLite e' veramente eccellente,
ed anche notevolmente efficiente (=veloce)
ti puoi sbizzarrire a piacer tuo facendoci cose veramente
pazzesche: certo, e' sicuramente richiesta una buona familiarita'
con SQL e Spatial SQL, non sono esattamente il top dell'user
friendly ... in compenso offrono una potenza quasi infinita :wink:

ciao Sandro

On Wed, Dec 11, 2013 at 05:26:24PM +0100, a.furieri@lqt.it wrote:

On Wed, 11 Dec 2013 16:56:20 +0100, Andrea Peri wrote:
>Ci sarebbe il ROWID.
>E' un attributo hidden che sqlite aggiunge sempre sistematicamente a
>ogni tabella che viene creata.
>
>Ma è a livello di tabella, non so' se la sua visibilita' si espande
>fino alla vista.
>

dov'e' il problema ?
qualsiasi tavola (vedi sotto per l'eccezione alla regola) ha sempre
una propria colonna "fantasma" di nome ROWID, che e' semplicemente
un alias name ma che sintatticamente funziona esattamente come
qualsiasi altro nome-colonna.

Sandro e Andrea, vedere queste cose mi fa pensare che un Dio c'\`e
(permettetemi la finezza da TeXnician)... In epoca di UTF8 anche voi
insistete ad usare le accentate old fashion con apostrofo e codifica
US-ASCII. E magari lo US layout di tastiera invece dell'abominevole
tastiera italiana.

--
Francesco P. Lovergine