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:

    Java
    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:


    Java
    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 :)

  • Na, dann bleibt ja nur noch zu erwähnen, dass BLOBs in Datenbanken immer eine unglaublich schlechte Idee sind und Du lieber Pfadangaben hinterlegen solltest. :P

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • 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. :P


    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. :)

  • Ich schiebe Bilder und Dateien seit ca. 2007 nur noch in die Datenbank. Bisher hatte ich dadurch keinen spürbaren Nachteil. Backups sind auch einfacher, da man nur doch die Datenbank sichern muss. Nachteil mit Dateien in der Datenbank entsteht erst, wenn man diese Daten über einen schnellen Webserver bereitstellen will (z.B. NGINX) oder in ein CDN hochladen will. Oft ist es dann etwas schwieriger, aber lässt sich auch lösen, indem man benötigte Dateien einfach aus der DB in Verzeichnisstrukturen schreibt und dann doppelt pflegt oder direkt via OutputStream hochlädt.

  • Das Problem an SQLite Datenbanken ist ja, dass sie dateibasiert sind.
    Solange Du also irgendwo lesend irgend ein Bild aus Deiner Datenbank lädst, hast Du keinen Zugriff auf weitere Daten aus Deiner Datenbank.
    Mag bei modernen Geräten mittlerweile egal geworden sein, ich bin da ein wenig altmodisch.


    Eine weitere Sache, die meiner Meinung nach gegen BLOBs spricht, ist die Zugriffsfähigkeit.
    Die ist stumpf nicht vorhanden.


    Wenn die Dinger in eine Datenbank eingetragen werden (können), dann hat der User ja irgendwie dafür gesorgt, dass die Daten da drin liegen.
    Sagen wir, er hat ein Foto geschossen oder eine Sprachaufzeichnung gemacht.


    Wenn er dieses Foto oder diese Sprachaufzeichnung jetzt beispielsweise auch noch per WhatsApp an seine Schwester schicken möchte, dann muss er sich darauf verlassen, dass Deine App eine 'Sharing' Funktion für WhatsApp, eine Exportfunktion oder ähnlichen umständlichen Kram anbietet.
    Schlimmer noch: das Foto wird einerseits auf dem Dateisystem abgelegt und in der Datenbank Deiner App. Jetzt löscht er das Foto, weil er beim Versuch sein gebrochenes Bein zu fotografieren sein Geschlechtsteil mit im Bild eingefangen hat, was ihm unangenehm ist.
    Der nächste, der dann Deine App aufmacht, findet das Foto, exportiert es und stellt es öffentlich auf Facebook – dumm, da der User eigentlich davon ausgehen konnte, dass das Bild weg ist.


    Ich bin ja der Auffassung, in Datenbanken gehören all diejenigen veränderbaren Dinge, die der App gehören: Texte.
    Alle anderen veränderbaren Dinge gehören der App nicht, ergo haben sie auch nichts in einer Datenbank verloren.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • 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 :D

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!