Image als Blob in der SQLite speichern

Guten Abend liebe Community,

auch ich wende mich mal wieder mit einer Frage an euch

Mein Anliegen ist es, ein Bild als Bytearray in der Android SQLite zu speichern. (Ja ich könnte es auch ins Filesystem packen, aber ich kann eben auch die DB nehmen :P)
Der Quellcode dazu sieht so aus:

public static int editListEntry(Context context, String column, int id, byte[] image) {
		ContentValues editedValues = new ContentValues();
		editedValues.put(column, image);


		return context.getContentResolver().update(DatabaseProvider.CONTENT_URI,
				editedValues, Columns.COL_ID + " = ?", new String [] { String.valueOf(id) });
	}

Ich mache das über update, weil zur Zeit der Erstellung des Datenbankeintrags die Bilder noch nicht zur Verfügung stehen.
Mein Problem ist nun, dass der Rückgabewert 0 ist und nicht 1. Bei einem Test ob die Bilder in der DB sind, ergab sich auch das nichts geupdated wurde.
Ich weiß einfach nicht wieso, es kommt auch keine Fehlermeldung.

Der Parameter "id" ist die ID des Datenbankeintrags der geupdated werden soll.
Die Variable image enthält das Bytearray des Bildes, welches mit dieser Methode ermittelt wurde:

private byte[] getByteArray(Bitmap bmp) {
		ByteArrayOutputStream stream = new ByteArrayOutputStream();
		bmp.compress(Bitmap.CompressFormat.PNG, 100, stream);


		return stream.toByteArray();
	}

Hat von euch einer eine Idee warum der returnwert von editListEntry 0 beträgt?

LG.
ChampS

Das ist die where bedingung, Col_ID eine Konstant mit dem name der Spalte und das fragezeichen wird durch den inhalt des string arrays ersetzt.

Edit:
Ok Problem gelöst, es war ein ganz einfaches und vorallem dummes Problem *gg*.
Die ID war einfach 0.
Ich habe einfach vergessen beim schreiben in die DB die ID des Eintrags in meine Liste zu speichern, somit ist die ID die reingegeben wurde immer die standard ID meines Listeneintrags und die ist 0.

Der Blob wird nun wunderbar gespeichert und DDMS in Eclipse zeigt mir mit dem Datenbank tool sogar direkt die gespeicherten Bilder an

Nein, da muss ich widersprechen.
Ich erzeuge dynamisch neue Daten und Bilder und lösche veraltete. Ich müsste ständig auf dem Filesystem schreiben/lesen und in die DB schreiben/lesen. In meiner Variante werden die Bilder gleichzeitig mit den Dazugehörigen Daten gelöscht und neu geschrieben. Es ist einfach unnötig eine zweite Infrastruktur zu etablieren wenn es alles ohne Nachteile mit einer funktioniert.

Einige posts im Netz meinten sogar das die Blobs in der DB sogar schneller sind als wenn man auf dem Filesystem arbeitet, das kann ich aber nich beurteilen.

Das stimmt nur bedingt, denn Lesezugriff sollte trotzdem möglich sein. Ich weiß nicht wie Android das händelt, aber möglich wäre es.
Es kommt halt auch auf die größe der Bilder drauf an. Wie du schon sagtest spielt es heute kaum noch eine Rolle, außer eben wenn man da gleichmal Bilder mit mehreren hundert MB reinwirft. Ich glaube ich teste das heute abend mal, das will ich jetzt wissen wie Android damit umgeht *gg*.

Nunja ich sehe deinen zweiten Punkt eher als Vorteil!
Da würde ich gern die app Threema als Vorbild nennen, denn dort musst du explizit die mediendaten anwählen und aufs dateisystem exportieren wenn du sie dort haben möchtest. Das hat den Vorteil das eben nicht jeder Zugriff auf deine Daten im Dateisystem hat und du die Mediendatei beispielsweise verschlüsselt in der DB der app liegen lassen kannst, bis der User sich dazu entscheidet diese aufs Dateisystem zu exportieren. Das ist eben eine Standpunkt bzw. Anwendungsfall Geschichte. Je nachdem was du machen möchtest, musst du abwägen was wichtiger ist. Meine App ist nur eine einfache Mensaapp die Bilder von Essen anzeigt, das möchte vermutlich kein User per Whatsapp versenden *gg*. Bzw. Für diesen Fall werde ich noch eine Kamerafunktion einbauen das man sein Essen Fotografieren kann und dann auf Facebook posten kann, aus der App heraus, ist mir gerade so in den Sinn gekommen