Android SQLite getColumnIndex

T

Tomate_Salat

Gast
Hallo,

der Cursor kennt ja die Methode getColumnIndex, welche an sich ja gut funktioniert. Allerdings könnte sich das ändern, sobald joins ins spiel kommen.
.[columnname] scheint er ab und zu mal zu nehmen, aber für einige Felder fliegen mir dann exceptions um die ohren die die App ganz schön ausbremsen. Kennt ihr da eine Möglichkeit, wie ich eben soetwas ähnliche wie table.columname umsetzen kann oder habt alternativvorschläge?

Kleine Randinformation: das ganze wird in meinem kleinen ORM eingesetzt und sollte von daher automatisiert ablaufen können.
 

schlingel

Gesperrter Benutzer
Wie sieht denn die Logik aus die, die Queries generiert? Praktisch würde sich ja anbieten, dass du die einzelnen Felder im SELECT benennst. Also mit einem SELECT column as TABLENAME + "_" + COLUMNNAME ... regelst. Dann sollte auch getColumnName funktionieren.
 
T

Tomate_Salat

Gast
Die logik ist sehr simpel gehalten.
"SELECT * FROM [TABELLE] {JOINS} (WHERE) (HAVING) (ORDER BY)"
- Tabelle wird vom model gelesen und eingesetzt
- JOINS werden nach gebrauch generiert
- alles in ()-Klammern kann optional hinzugefügt werden.

Dazu müsste ich eben den SELECT * anpassen. Problematisch wird es nur bei eigen-geschriebenen Selects, wo sich der "Autor" nicht an die Konvention hält/sie nicht kennt.
 
T

Tomate_Salat

Gast
Yay!

Hab da bisher noch nicht weitergemacht, aber jetzt ist die kacke am Dampfen (um es mal auf gutdeutsch zu sagen). Hab 2 Joins auf die gleiche Tabelle und oh wunder: die Werte vom einen join werden vom anderen überschrieben.

Debuggen+ein blick in den Source von SQLiteCursor & Freunde bestätigen aber nur, was ich befürchtet habe. An die Informationen, an die ich ran möchte, käme ich nichtmal mit Reflection dran - es gibt sie einfach nicht =(.

Also bleibt mir tatsächlich nur noch das auflösen des [c]*[/c] im SELECT :(
 

schlingel

Gesperrter Benutzer
Dann muss deine Logik auch beachten, das ein Tabellenname mehrfach vorkommen kann. Mein aus der Hüfte geschossener Vorschlag oben würde auch scheitern.
 
T

Tomate_Salat

Gast
Da würde ich als Tabellenalias einfach den Feldnamen in der entsprechenden Klasse nehmen.
Leider hat diese Methode aber auch seine Nachtteile. Da darf ich z.B. bestehende [c]WHERE[/c] umschreiben (in der Hoffnung, nichts zu vergessen).

Ich werde mal das Problem etwas mehr studieren müssen. Den Fall werde ich halt etwas unbequemer lösen, indem ich eben diese OneToOne-Beziehungen erstmal aus der betroffenen Klasse entferne.
 
T

Tomate_Salat

Gast
Denke ich konnte es lösen. Und zwar mache ich folgendes:
Die Anweisung [c]SELECT *[/c] hab ich geändert in: [c]SELECT {table}.*[/c]. {table} ist dabei die Haupttabelle (die auch im FROM steht).

Kommen Joins hinzu, so bekommen betroffene Tabellen einen Alias der dem Feldnamen in der Klasse entspricht:

Java:
@OneToOne @JoinColumn(name="id")
private Ort wohnort;

Daraus würde er dann machen [c]LEFT JOIN ort wohnort ON {table}.id=wohnort.id[/c] und den Select erweitert er dann um folgende Felder:
[c], wohnort.id AS wohnort_id, wohnort.ort AS wohnort_ort[/c] usw.

Damit schreibe ich so wenig wie nötig um, habe aber doch noch alle Informationen. Ich muss noch meine Tests anpassen, aber in der App scheint es schonmal zu funktionieren ... juchu :)
 

Neue Themen


Oben