L'aspetto importante non è la tabella o le tabelle, ma la query stessa in quanto determina l'ordine delle colonne.
Ad esempio se la query fosse basata su SELECT * FROM your_table (e le colonne nella tabella sono state definite come id, songname, songyear, songpath), quindi la colonna è il cursore sarebbe come da definizione.
Tuttavia, se hai fatto SELECT songname, songpath, songid, songyear FROM your_table;
L'ordine sarebbe come da SELECT istruzione ovvero nome del brano (0), percorso del brano (1), ID del brano (2), anno del brano (3).
Tuttavia, questo è uno dei problemi con l'utilizzo degli offset che sei legato all'ordine secondo SELECT.
Ora, se hai utilizzato getColumnIndex del cursore metodo quindi che restituisce l'offset della colonna in base al suo nome.
Quindi cursor.getString(cursor.getColumnIndex("songpath")); otterrebbe la colonna del percorso della canzone indipendentemente dal suo offset/posizione nel cursore (SE IL CURSORE INCLUDE QUELLA COLONNA).
Ricordando la tua domanda precedente, in pratica avevi SELECT songpath FROM your_table , In quanto tale c'è solo una singola colonna nel cursore risultante, quindi puoi usare solo get :-
cursor.getString(0);
oppure :-
cursor.getString(cursor.getColumnIndex("songpath"));
Quest'ultimo è il metodo consigliato (MA idealmente i nomi delle colonne sono definiti come costanti)
Tuttavia, le cose possono diventare più complicate, ad esempio considera
SELECT songpath||songname AS myconfusingcolumn FROM yourtable;
Ciò restituirebbe una singola colonna denominata myconfusingcolumn che consiste nel percorso della canzone concatenato con il nome della canzone. Cioè la parola chiave AS è seguita da un alias per la colonna (senza AS il nome della colonna sarebbe ancora più confuso/difficile come sarebbe percorsocanzone||nomecanzone) (questo esempio è relativamente semplice).
Un'altra cosa di cui diffidare è che sono ambigui colonne (nomi di colonne duplicati), ad esempio, se avevi due tabelle song e artist e song la colonna aggiuntiva artist_id in modo da avere :-
La canzone tabella con colonne id , nome del brano , anno canoro , percorso dei brani , id_artista
Gli artisti tabella con colonne id e nome_artista
e poi hai usato
SELECT * FROM song JOIN artist ON song.artist_id = artist.id;
- Tieni presente che come id colonna dell'artista tabella, se utilizzata nell'istruzione, deve essere preceduta dal rispettivo nome della tabella, altrimenti verrebbe generato un errore di colonna AMBIGUOUS, ovvero il parser SQL non saprebbe quale id colonna intendi.
Inoltre ti ritroveresti con un cursore con colonne :-
id , nome del brano, anno del brano, percorso del brano, ID_artista, id , nome_artista
csr.getLong(csr.getColumnIndex("id")); could get confused (I believe it actually gets the last AMBIGUOUS column)
long songid = csr.getLong(0); would get the id column from the song table.
long artistid = csr.getLong(5); would get the id column from the artist table.
long artistid = csr.getLong(4); would also get the artist_id same as (5).
Per ricapitolare/riassumere :-
Le colonne, l'ordine e il nome, in un cursore dipendono interamente dalla query SELECT. Avranno un offset e un nome secondo la query. Quando si accede al cursore, i nomi delle tabelle sottostanti non sono utilizzabili solo i nomi delle colonne o gli offset.
È più flessibile accedere alle colonne in base ai loro nomi piuttosto che in base alle loro dipendenze . Vale a dire utilizzare il getColumnIndex del cursore metodo in quanto annulla la necessità di calcolare gli offset e, in particolare, il ricalcolo mancante in caso di modifica di una query.
L'utilizzo di CONSTANTS per i nomi delle colonne comporterà probabilmente una riduzione dei problemi come gli errori di battitura.
Ulteriori
Usando Toast.makeText(this, mListSongs+"", Toast.LENGTH_SHORT).show();
Otterrà il risultato insolito [{}] perché mListSongs è l'intero contenitore per i brani. Devi scorrere ogni elemento e quindi ottenere le proprietà/valori per ogni membro/variabile dall'elemento (oggetto Song).
