Ważnym aspektem nie jest tabela ani tabele, ale samo zapytanie, które określa kolejność kolumn.
Na przykład, jeśli zapytanie zostało oparte na SELECT * FROM your_table (a kolumny w tabeli zostały zdefiniowane jako id, nazwa utworu, rok utworu, ścieżka utworu), a następnie w kolumnie znajduje się kursor zgodnie z definicją.
Jeśli jednak wykonałeś SELECT songname, songpath, songid, songyear FROM your_table;
Kolejność będzie zgodna z WYBIERZ oświadczenie, tj. nazwa utworu (0), ścieżka utworu (1), identyfikator utworu (2), rok utworu (3).
Jest to jednak jeden z problemów związanych z używaniem offsetów, które są powiązane z zamówieniem zgodnie z SELECT.
Teraz, jeśli użyłeś getColumnIndex kursora metoda, która zwraca przesunięcie kolumny zgodnie z jej nazwą.
Więc cursor.getString(cursor.getColumnIndex("songpath")); otrzyma kolumnę ścieżki utworu niezależnie od jej przesunięcia/położenia w Kursorze (JEŚLI KURSORA ZAWIERA TA KOLUMNĘ).
Przypominając twoje poprzednie pytanie, w zasadzie miałeś SELECT songpath FROM your_table , W związku z tym w wynikowym Kursorze jest tylko jedna kolumna, więc możesz użyć tylko get :-
cursor.getString(0);
lub :-
cursor.getString(cursor.getColumnIndex("songpath"));
Ta ostatnia jest zalecaną metodą (ALE najlepiej mieć nazwy kolumn zdefiniowane jako stałe)
Sprawy mogą się jednak skomplikować, na przykład rozważ
SELECT songpath||songname AS myconfusingcolumn FROM yourtable;
Zwróci to pojedynczą kolumnę o nazwie myconfusingcolumn, która składa się ze ścieżki utworu połączonej z nazwą utworu. Oznacza to, że po słowie kluczowym AS następuje alias kolumny (bez AS nazwa kolumny byłaby jeszcze bardziej myląca/trudna, ponieważ byłaby to ścieżka utworu||nazwa utworu) (ten przykład jest stosunkowo prosty).
Kolejną rzeczą, na którą należy uważać, jest to, że są niejednoznaczne kolumny (zduplikowane nazwy kolumn), na przykład, jeśli masz dwie tabele utwór i wykonawca i piosenka dodatkowa kolumna artist_id, więc masz :-
piosenka tabela z kolumnami id , nazwa utworu , rok utworu , ścieżka utworu , artist_id
Artyści tabela z kolumnami id i nazwa_wykonawcy
a następnie użyłeś
SELECT * FROM song JOIN artist ON song.artist_id = artist.id;
- Zauważ, że jako id kolumna artysty tabela, jeśli zostanie użyta w instrukcji, musi być poprzedzona odpowiednią nazwą tabeli, w przeciwnym razie zostanie zgłoszony błąd kolumny AMBIGUOUS, tj. parser SQL nie będzie wiedział, który id kolumna, którą masz na myśli.
Co więcej, otrzymasz kursor mający kolumny :-
identyfikator , tytuł utworu, rok utworu, ścieżka utworu, identyfikator wykonawcy, id , nazwa_artysty
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).
Aby podsumować/podsumować:-
Kolumny, kolejność i nazwa w Kursorze są całkowicie zależne od zapytania SELECT. Będą miały przesunięcie i nazwę zgodnie z zapytaniem. Podczas uzyskiwania dostępu do Kursora nie można używać nazw bazowych tabel, tylko nazw kolumn lub przesunięć.
Bardziej elastyczny jest dostęp do kolumn po ich nazwach, a nie po ich pominięciu . To znaczy skorzystaj z getColumnIndex kursora metoda, ponieważ neguje potrzebę obliczania przesunięć, a zwłaszcza brakujące ponowne obliczenie w przypadku zmiany zapytania.
Użycie CONSTANTS dla nazw kolumn prawdopodobnie zmniejszy liczbę problemów, takich jak błędy pisowni.
Dodatkowe
Używanie Toast.makeText(this, mListSongs+"", Toast.LENGTH_SHORT).show();
Otrzyma nietypowy wynik [{}], ponieważ mListSongs to cały pojemnik na utwory. Musisz przejść przez każdy element, a następnie pobrać właściwości/wartości dla każdego elementu/zmiennej z elementu (obiektu utworu).
