Důležitým aspektem není tabulka nebo tabulky, ale samotný dotaz, který určuje pořadí sloupců.
Například pokud byl dotaz založen na SELECT * FROM your_table (a sloupce v tabulce byly definovány jako id, název skladby, rok skladby, cesta skladby), pak sloupec je kurzor podle definice.
Pokud jste však SELECT songname, songpath, songid, songyear FROM your_table;
Pořadí bude podle VYBRAT prohlášení, tj. název skladby (0), cesta skladby (1), ID skladby (2), rok skladby (3).
To je však jeden z problémů s použitím offsetů, které jste vázáni na objednávku podle SELECT.
Nyní, pokud jste použili kurzor getColumnIndex metoda pak vrátí posun sloupce podle jeho názvu.
Takže cursor.getString(cursor.getColumnIndex("songpath")); by získal sloupec cesty skladby bez ohledu na jeho posun/polohu v kurzoru (POKUD KURZOR ZAHRNUJE TENTO SLOUPEC).
Při vzpomínce na vaši předchozí otázku jste v podstatě měli SELECT songpath FROM your_table , Ve výsledném kurzoru je tedy pouze jeden sloupec, takže můžete použít pouze get :-
cursor.getString(0);
nebo :-
cursor.getString(cursor.getColumnIndex("songpath"));
Poslední jmenovaný je doporučený způsob (ALE v ideálním případě mějte názvy sloupců definované jako konstanty)
Věci se však mohou zkomplikovat, například zvažte
SELECT songpath||songname AS myconfusingcolumn FROM yourtable;
To by vrátilo jeden sloupec s názvem myconfusingcolumn, který se skládá z cesty skladby spojené s názvem skladby. To znamená, že za klíčovým slovem AS následuje alias pro sloupec (bez AS by byl název sloupce ještě matoucí/obtížnější, protože cesta k písni||název skladby) (tento příklad je poměrně jednoduchý).
Další věc, na kterou je třeba si dát pozor, je nejednoznačné sloupce (duplicitní názvy sloupců), například pokud jste měli dvě tabulky song a interpret a song další sloupec artist_id, takže máte :-
píseň tabulka se sloupci id , název skladby , rok skladby , skladba , id_umělce
umělci tabulka se sloupci id a jméno_umělce
a poté jste použili
SELECT * FROM song JOIN artist ON song.artist_id = artist.id;
- Všimněte si, že jako id sloupec interpret tabulka, pokud je použita v příkazu, musí mít předponu s příslušným názvem tabulky, jinak by byla vyvolána NEJMYSLNÁ chyba sloupce, tj. analyzátor SQL by nevěděl, které id sloupec máte na mysli.
Navíc byste skončili s kurzorem se sloupci :-
id , název skladby, rok skladby, cesta skladby, id_interpreta, id , jméno_umělce
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).
Pro rekapitulaci/shrnutí :-
Sloupce, pořadí a název v kurzoru jsou zcela závislé na dotazu SELECT. Budou mít posun a název podle dotazu. Při přístupu ke kurzoru nelze použít základní názvy tabulek, pouze názvy sloupců nebo offsety.
Je flexibilnější přistupovat ke sloupcům podle jejich názvů než podle jejich vedlejších . To znamená využít getColumnIndex kurzoru metoda, protože neguje potřebu počítat offsety a zejména chybějící přepočet v případě změny dotazu.
Použití KONSTANT pro názvy sloupců pravděpodobně povede ke snížení problémů, jako jsou překlepy.
Další
Pomocí Toast.makeText(this, mListSongs+"", Toast.LENGTH_SHORT).show();
Získá neobvyklý výsledek [{}], protože mListSongs je celý kontejner pro Songs. Musíte procházet každý prvek a poté získat vlastnosti/hodnoty pro každý člen/proměnnou z prvku (objektu Song).