diff options
author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:15 -0500 |
---|---|---|
committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:15 -0500 |
commit | 4b1a9203c547c019fc5398082ae19a3f3d4c3efe (patch) | |
tree | d4a40e13ceeb9f85479605110a76e7a4d5f3b56b /files/de/web/api/indexeddb_api | |
parent | 33058f2b292b3a581333bdfb21b8f671898c5060 (diff) | |
download | translated-content-4b1a9203c547c019fc5398082ae19a3f3d4c3efe.tar.gz translated-content-4b1a9203c547c019fc5398082ae19a3f3d4c3efe.tar.bz2 translated-content-4b1a9203c547c019fc5398082ae19a3f3d4c3efe.zip |
initial commit
Diffstat (limited to 'files/de/web/api/indexeddb_api')
4 files changed, 1757 insertions, 0 deletions
diff --git a/files/de/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html b/files/de/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html new file mode 100644 index 0000000000..436886fe21 --- /dev/null +++ b/files/de/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html @@ -0,0 +1,131 @@ +--- +title: Browser storage limits and eviction criteria +slug: Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria +tags: + - Datenbank + - Datenlöschung + - IndexDB + - Speicher + - Speicherung + - client-seitig +translation_of: Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria +--- +<div>{{DefaultAPISidebar("IndexedDB")}}</div> + +<p class="summary">Es gibt eine Reihe von Web-Technologien, die Daten auf die eine oder andere Art und Weise client-seitig speichern (bspw. auf der lokalen Festplatte). Der Prozess, durch welchen der Browser bestimmt, wieviel Speicherplatz er der Webdatenspeicherung zur Verfügung stellen soll, und was gelöscht werden soll, wenn dieses Limit erreicht wurde, ist nicht einfach und unterscheidet sich zwischen verschiedenen Browsern. Dieser Artikel versucht zu erklären, wie dies funktioniert.</p> + +<div class="note"> +<p><strong>Info</strong>: Die untenstehenden Informationen sollten für die meisten modernen Browser zutreffen. Wo bekannt, werden browserspezifische Eigenheiten benannt. Opera und Chrome sollten sich in allen Fällen gleich verhalten. <a href="http://www.opera.com/mobile/mini">Opera Mini</a> (noch presto-basiert, serverseitiges Rendering) speichert kein Daten lokal auf dem Client.</p> +</div> + +<h2 id="Welche_Technologien_nutzen_Browser_zur_lokalen_Datenspeicherung">Welche Technologien nutzen Browser zur lokalen Datenspeicherung?</h2> + +<p>In Firefox werden die folgenden Technologien eingesetzt, um Daten lokal bei Bedarf zu sichern. Wir bezeichnen sie in diesem Zusammenhang als "Quota Clients" :</p> + +<ul> + <li><a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a></li> + <li><a href="http://asmjs.org/">asm.js</a> caching</li> + <li><a href="/en-US/docs/Web/API/Cache">Cache API</a></li> + <li>Cookies</li> +</ul> + +<div class="note"> +<p><strong>Info</strong>: In Firefox, <a href="/en-US/docs/Web/API/Web_Storage_API">Web Storage</a> wird bald die gleichen Speichermanagement Tools wie in diesem Dokument beschrieben einsetzen.</p> +</div> + +<div class="note"> +<p><strong>Info</strong>: Im privaten Browsermodus werden die meisten Speichermethoden nicht unterstützt. Local storage Daten und Cookies werden zwar noch immer gespeichert, aber sie sind flüchtig — sie werden gelöscht, wenn das letzte private Browserfenster geschlossen wurde.</p> +</div> + +<p>Die "letzte Zugriffszeit" der Quelle wird aufdatiert wenn irgendeine von ihnen aktiviert oder deaktiviert wird — die Löschung der Quelle löscht die Daten für alle diese "Quota Clients".</p> + +<p>In Chrome/Opera kümmert sich die Quota Management API um das Quota Management für den <a href="/en-US/docs/Web/HTML/Using_the_application_cache">AppCache</a>, die <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>, WebSQL und die <a href="/en-US/docs/Web/API/File_System_API">File System API</a>.</p> + +<h2 id="Unterschiedliche_Typen_der_Datenspeicherung">Unterschiedliche Typen der Datenspeicherung</h2> + +<p>Sogar wenn man die gleiche Speichermethode im gleichen Browser verwendet, muss man unterschiedliche Klassen der Datenspeicherung verstehen. Dieser Abschnitt behandelt die Unterschiede in verschiedenen Browsern.</p> + +<p>Speicherung kann auf zwei Arten vorkommen:</p> + +<ul> + <li>Persistent: Persistente Daten sollen für einen längeren Zeitraum zur Verfügung stehen. Sie werden nur gelöscht, wenn sich der Benutzer aktiv dazu entschließt (zum Beispiel kann man in Firefox und Chrome auswählen, alle Daten oder nur Daten von bestimmten Seiten zu löschen, indem man dies über <em>Einstellungen</em> und <em>Datenschutz & Sicherheit > Websitedaten</em> auswählt).</li> + <li>Temporär: Diese Daten müssen nicht über einen längeren Zeitraum gespeichert werden. Sie werden in der Reihenfolge gelöscht, wie sie am wenigsten benutzt wurden ({{anch("LRU policy")}}) sobald {{anch("Storage limits")}} erreicht wurden.</li> +</ul> + +<p>Sobald persistente Daten gespeichert werden sollen, bekommt ein Benutzer in Firefox eine Popup-Warnung, um darauf hinzuweisen, dass die Daten dauerhaft gespeichert werden sollen und fragt gleichzeitig ab, ob er damit einverstanden ist. Temporäre Datenspeicherung löst nicht eine solche Warnung aus.</p> + +<p>Datenspeicherung ist standardmäßig temporär. Entwickler können die Nutzung persistenten Speichers durch Aufruf der Methode {{domxref("StorageManager.persist()")}} aus der <a href="/en-US/docs/Web/API/Storage_API">Storage API</a> erreichen.</p> + +<h2 id="Wo_werden_die_Daten_gespeichert">Wo werden die Daten gespeichert?</h2> + +<p>Jeder Speichertyp nutzt ein eigenes Repository. Hier ist ein konkretes Mapping auf die Verzeichnisse im Profil eines Firefox Benutzers (andere Browser können hiervon leicht abweichen):</p> + +<ul> + <li><code><profile>/storage</code> — das Hauptverzeichnis für Speicher, die durch den Quota Manager verwaltet werden (siehe unten)</li> + <li><code><profile>/storage/permanent</code> — Repository für die Speicherung persistenter Daten</li> + <li><code><profile>/storage/temporary</code> — Repository für die Speicherung temporärer Daten</li> + <li><code><profile>/storage/default</code> — Standard-Repository für die Speicherung von Daten</li> +</ul> + +<div> +<div class="note"> +<p><strong>Info</strong>: Nach Einführung der <a href="/en-US/docs/Web/API/Storage_API">Storage API</a> kann das "permanent" Verzeichnis als obsolet bestrachtet werden. Das "permanent" Verzeichnis beinhaltet nur noch persistente IndexedDB Datenbasen. Es macht keinen Unterschied, ob der box mode "best-effort" oder "persistent" ist — die Daten werden unter <profile>/storage/default abgelegt.</p> +</div> +</div> + +<div class="note"> +<p><strong>Info</strong>: In Firefox kann man sein Profilverzeichnis aufrufen, indem man <code>about:support</code> in die URL Adresszeile eingibt und den <em>Ordner öffnen</em> Knopf in der Zeile <em>Profilordner</em> drückt.</p> +</div> + +<div class="note"> +<p><strong>Info</strong>: Wenn man im Profilordner in den Datenspeicherordnern sucht, findet man noch einen vierten Ordner namens <code>persistent</code>. Der <code>persistent</code> Ordner wurde ursprünglich vor einer Weile in <code>permanent</code> umbenannt, um Upgrades und Migrationen zu vereinfachen.</p> +</div> + +<div class="note"> +<p><strong>Info</strong>: Benuter sollten unter dem Verzeichnis <code><profile>/storage</code> keine eigenen dateien oder Verzeichnisse anlegen. Dies führt dazu, dass die Speicherinitialisierung fehlschlägt; zum Beispiel führt dann {{domxref("IDBFactory.open()", "open()")}} zu einem Fehlerevent.</p> +</div> + +<h2 id="Speichergrenzen">Speichergrenzen</h2> + +<p>Der maximale Speicherplatz des Browsers ist dynamisch — er basiert auf der Größe der Festplatte. Das <strong>globale Limit</strong> berechnet sich als 50% des freien Plattenspeichers. In Firefox überwacht ein internes Tool namensQuota Manager wieviel Speicher jede Quelle nutzt und löscht gegebenenfalls Daten.</p> + +<p>Wenn die Festplatte 500 GB freien Speicher aufweist, ist die maximale Größe des Speichers 250 GB. Wenn diese Größe überschritten wird, kommt ein Prozess namens <strong>origin eviction</strong> ins Spiel, welcher die kompletten Daten einzelner Quellen löscht, bis diese Größe wieder unterschritten wurde. Es werden nie Teile von Quellen gelöscht, da teilweise Daten einer Quelle zu Inkonsistenzen führen können.</p> + +<p>Zudem gibt es eine weitere Begrenzung namens <strong>Gruppenlimit</strong> — dieses ist definiert als 20% des globalen Limits, aber hat ein Minimum von 10 MB und ein Maximum von 2 GB. Jede Quelle ist Teil einer Gruppe (Gruppe von Quellen). Es gibt eine Gruppe für jede eTLD+1 Domain. Zum Beispiel:</p> + +<ul> + <li><code>mozilla.org</code> — Gruppe 1, Quelle 1</li> + <li><code>www.mozilla.org</code> — Gruppe 1, Quelle 2</li> + <li><code>joe.blogs.mozilla.org</code> — Gruppe 1, Quelle 3</li> + <li><code>firefox.com</code> — Gruppe 2, Quelle 4</li> +</ul> + +<p>Innerhalb dieser Gruppe, <code>mozilla.org</code>, <code>www.mozilla.org</code>, und <code>joe.blogs.mozilla.org</code> können zusammen ein Maximum von 20% des globalen Limits nutzen. <code>firefox.com</code> hat als weitere Gruppe ein separates Maximum von 20%.</p> + +<p>Beide Limits haben unterschiedliche Auswirkungen, wenn sie erreicht werden:</p> + +<ul> + <li>Das Gruppenlimit ist eine harte Grenze: es löst keien Datenlöschung aus.</li> + <li>Das globale Limit ist eine weiche Grenze, da eine Möglichkeit besteht, dass durch die ausgelöste Datenlöschung Speicher frei wird und sofort genutzt werden kann.</li> +</ul> + +<div class="note"> +<p><strong>Info</strong>: Das Gruppenlimit kann nie mehr als das globale Limit sein. Bei extrem niedrigen Speicherstand von beispielsweisen 8MB globalen Limit, ist das Gruppenlimit ebenfalls nur 8MB.</p> +</div> + +<div class="note"> +<p><strong>Note</strong>: Wenn das Gruppenlimit überschritten wird oder eine ausgelöste automatische Datenlöschung nicht genug Speicher freiräumen kann, wirft der Browser einen <code>QuotaExceededError</code>.</p> +</div> + +<h2 id="LRU_Policy">LRU Policy</h2> + +<p>Wenn der verfügbare Speicherplatz aufgebnraucht wurde, startet das Quota Management eine Datenlöschung nach der LRU (Least Recently Used) Policy — die Daten der am längsten nicht benutzten Quellen werden zuerst gelöscht, dann die zweitältesten usw., bis der Browser wieder unter das Speicherlimit fällt.</p> + +<p>Die letzte Zugriffszeit für jede Quelle wird im temporären Speicher vorgehalten. Sobald das globale Limit für temporären Speicher erreicht wurde, (mehr dazu später), werden alle derzeit ungenutzten Quellen identifiziert (z.Bsp., ohne offene Tabs oder Apps, die aktuell auf den Datenspeicher zugreifen). Diese werden dann nach der letzten Zugriffszeit sortiert. Die am längsten ungenutzten Daten werden dann zuerst gelöscht, bis genug Speicher frei wird, dass die Operation ausgeführt werden kann, die zur Auslösung der Datenlöschung verantwortlich war.</p> + +<h2 id="Siehe_auch">Siehe auch</h2> + +<ul> + <li><a href="http://www.html5rocks.com/en/tutorials/offline/quota-research/">Working with quota on mobile browsers</a>, von<a href="http://blog.agektmr.com" title="Eiji Kitamura"> Eiji Kitamura.</a> Eine detaillierte Analyse client-seitiger Speicherung in mobilen Browsern.</li> + <li><a href="https://developers.google.com/web/updates/2011/11/Quota-Management-API-Fast-Facts">Quota Management API: Fast Facts</a>, von<a href="http://blog.agektmr.com" title="Eiji Kitamura"> Eiji Kitamura.</a> Ein Blick auf die Quota Management API in Chrome/Blink (welche auch Opera berücksichtigen sollte).</li> +</ul> diff --git a/files/de/web/api/indexeddb_api/grundkonzepte_hinter_indexeddb/index.html b/files/de/web/api/indexeddb_api/grundkonzepte_hinter_indexeddb/index.html new file mode 100644 index 0000000000..6ae6f33dd7 --- /dev/null +++ b/files/de/web/api/indexeddb_api/grundkonzepte_hinter_indexeddb/index.html @@ -0,0 +1,194 @@ +--- +title: Grundkonzepte +slug: Web/API/IndexedDB_API/Grundkonzepte_hinter_IndexedDB +translation_of: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +--- +<p><strong>IndexedDB</strong> ermöglicht es Ihnen Daten innerhalb des Browsers eines Benutzers permanent abzulegen. Weil es Sie Webanwendungen mit funktionsreichen Abfragemöglichkeiten erstellen lässt, können diese Anwendungen sowohl online als auch offline funktionieren. IndexedDB ist geeignet für Anwendungen, die eine große Menge an Daten speichern (z.B. ein Katalog von DVDs in einer Videothek) und Anwendungen, die keine durchgehende Internetverbindung benötigen um zu funktionieren (z.B. E-Mail-Clients, To-Do-Listen oder Notizen).</p> +<h2 id="Über_dieses_Dokument">Über dieses Dokument</h2> +<p>Diese Einführung bespricht wesentliche Konzepte und Fachbegriffe in IndexedDB. Sie liefert Ihnen einen Gesamtüberblick und führt Sie in die Schlüsselkonzepte ein. Um mehr über die Begrifflichkeiten von IndexedDB zu erfahren, lesen Sie den Abschnitt <a href="#definitions">Definitionen</a>.</p> +<p>Eine Anleitung zur Verwendung der API finden Sie im Artikel <a href="/de/docs/IndexedDB/Using_IndexedDB" title="Using IndexedDB">Using IndexedDB</a>. Eine Referenzdokumentierung der IndexedDB-API finden Sie im Artikel <a href="/de/docs/IndexedDB" title="IndexedDB">IndexedDB</a> und dessen Unterseiten, welche die Objekttypen dokumentiert, die von IndexedDB verwendet werden, ebenso wie die Methoden von synchronen wie asynchronen APIs.</p> +<h2 id="Überblick_über_IndexedDB">Überblick über IndexedDB</h2> +<p>Mit IndexedDB lassen sich indizierte Objekte mit „Schlüsseln“ ablegen und abrufen. Alle Änderungen an der Datenbank geschehen innerhalb von Transaktionen. Wie die meisten Webspeicher-Lösungen folgt IndexedDB einer <a class="external" href="http://www.w3.org/Security/wiki/Same_Origin_Policy" title="Same Origin Policy">Same-Origin-Policy</a>. Während also auf Daten, die innerhalb einer Domain gespeichert wurden, zugegriffen werden kann, kann nicht domainübergreifend auf Daten zugegriffen werden.</p> +<p>Die API umfasst sowohl eine <a href="/en/IndexedDB#Asynchronous_API" title="https://developer.mozilla.org/en/IndexedDB#Asynchronous_API">asynchrone</a> API als auch eine <a href="/de/docs/IndexedDB#Synchronous_API" title="Synchronous API">synchrone</a> API. Die asynchrone API kann für die meisten Fälle verwendet werden, auch für <a href="/de/docs/Web/Guide/Performance/Using_web_workers" title="Using web workers">WebWorkers</a>, während die synchrone API nur für den Gebrauch durch WebWorkers gedacht ist. Momentan wird die synchrone API von keinem der großen Browser unterstützt. Aber selbst wenn synchrone APIs unterstützt wären, würden Sie eher die asynchrone API verwenden, wenn Sie mit IndexedDB arbeiten.</p> +<p>IndexedDB ist eine Alternative zur WebSQL-Datenbank, welche vom W3C am 18. November 2010 als veraltet erklärt wurde. Während sowohl IndexedDB als auch WebSQL Lösungen zur Speicherung von Daten bieten, bieten sie nicht dieselben Funktionalitäten. WebSQL-Datenbank ist ein relationales Datenbankanfragesystem, IndexedDB hingegen ist ein indiziertes Tabellensystem.</p> +<h2 id="concepts" name="concepts">Wichtige Konzepte</h2> +<p>Wenn Sie die Arbeit mit anderen Datenbanksystemen gewohnt sind kann die Arbeit mit IndexedDB am Anfang ungewohnt erscheinen. Behalten Sie deshalb folgende wichtige Konzepte im Hinterkopf:</p> +<ul> + <li> + <p><strong>IndexedDB-Datenbanken speichern Schlüssel-Wert-Paare.</strong> Die Werte können komplexe strukturierte Objekte sein, und Schlüssel können Eigenschaften dieser Objekte sein. Für eine schnelle Suche oder eine sortierte Aufzählung können Indizes erstellt werden, die irgendeine Eigenschaft der Objekte nutzen.</p> + </li> + <li> + <p><strong>IndexedDB baut auf einem Transaktions-Datenbankmodell auf.</strong> Alles, was Sie in IndexedDB tun, geschieht immer im Kontext einer <a href="#gloss_transaction">Transaktion</a>. Die IndexedDB-API bietet viele Objekte, die Indizes, Tabellen, Positionsmarken usw. repräsentieren, aber jedes einzelne dieser Objekte ist an eine bestimmte Transaktion gebunden. Deshalb können Sie außerhalb einer Transaktion keine Befehle ausführen oder Positionsmarken öffnen.</p> + <p>Transaktionen haben eine wohldefinierte Lebenszeit, deswegen führt der Versuch eine Transaktion zu verwenden, nachdem sie beendet ist, zu Exceptions. Außerdem führen Transaktionen ein Auto-Commit durch und können nicht von Hand committed werden.</p> + <p>Dieses Transaktionsmodell ist besonders nützlich im Hinblick auf was passieren könnte, wenn ein Benutzer zwei Instanzen einer Webapp gleichzeitig in verschiedenen Tabs öffnen würde. Ohne Transaktions-Operationen könnten die Änderungen der beiden Instanzen miteinander in Konflikt geraten. Wenn Sie mit Transaktionen in Datenbanken nicht vertraut sind, lesen Sie den <a class="link-https" href="https://de.wikipedia.org/wiki/Transaktion_(Informatik)" title="https://secure.wikimedia.org/wikipedia/en/wiki/Database_transaction">Wikipedia-Artikel über Transaktionen</a>. Eine weitere Beschreibung finden Sie außerdem im Abschnitt Definitionen bei <a href="#gloss_transaction">Transaktion</a>.</p> + </li> + <li> + <p><strong>Die IndexedDB API ist meistens asynchron.</strong> Die API übergibt Daten nicht, indem sie Werte zurückgibt; stattdessen muss eine Callback-Funktion übergeben werden. Daten werden nicht in der Datenbank <em>abgelegt</em> oder aus ihr mittels synchronen Methoden <em>abgerufen</em>. Stattdessen muss eine Datenbankoperation <em>angefordert</em> werden. DOM-Ereignisse informieren darüber, wenn die Operation beendet ist, und aus der Art des Ereignisses lässt sich erkennen, ob die Operation erfolgreich war oder fehlschlug. Das klingt zunächst etwas kompliziert, aber hier wurden einige vernünfte Maßnahmen umgesetzt. Diese Funktionsweise ist außerdem nicht so anders als die, mit der <a href="/de/docs/DOM/XMLHttpRequest" title="XMLHttpRequest">XMLHttpRequest</a> arbeitet.</p> + </li> + <li> + <p><strong>IndexedDB verwendet Anfragen, überall. </strong>Anfragen sind Objekte, die Erfolgs- oder Fehlschlag-DOM-Ereignisse erhalten, welche zuvor erwähnt wurden. Anfragen können die Eigenschaften <code style="font-size: 14px;">onsuccess</code> und <code style="font-size: 14px;">onerror</code> besitzen. Die Funktionen <code style="font-size: 14px;">addEventListener()</code> und <code style="font-size: 14px;">removeEventListener()</code> können auf ihnen ausgeführt werden. Sie haben außerdem die Eigenschaften <code style="font-size: 14px;">readyState</code>, <code style="font-size: 14px;">result</code>, und <code style="font-size: 14px;">errorCode</code>, die den Status der Anfrage mitteilen. Die Eigenschaft <code style="font-size: 14px;">result</code> ist besonders zauberhaft, da sie viele verschiedene Dinge darstellen kann, abhängig davon, wie die Anfrage erzeugt wurde (z.B. eine Instanz von <code style="font-size: 14px;">IDBCursor</code>, oder der Schlüssel zu einem Wert, den Sie gerade der Datenbank hinzugefügt haben).</p> + </li> + <li> + <p><strong>IndexedDB verwendet DOM-Ereignisse um Sie darüber zu informieren, wenn Ergebnisse verfügbar sind.</strong> DOM-Ereignisse haben immer die Eigenschaft <code style="font-size: 14px;">type</code> (in IndexedDB ist sie in den meisten Fällen auf „<code style="font-size: 14px;">success</code>“ oder „<code style="font-size: 14px;">error</code>“ gesetzt). DOM-Ereignisse haben außerdem eine Eigenschaft <code style="font-size: 14px;">target</code>, die Ihnen verrät in welche Richtung das Ereignis unterwegs ist. In den meisten Fällen ist das <code style="font-size: 14px;">target</code> eines Ereignisses das <code style="font-size: 14px;">IDBRequest</code> Objekt, das als Ergebnis einiger Datenbankoperationen erzeugt wurde. Success events don't bubble up and they can't be canceled. Error events, on the other hand, do bubble, and can be cancelled. Das ist recht wichtig, da Fehlerereignisse jede Transaktion, in der sie auftauchen, zu einem Abort führen, es sei denn diese wird annulliert (cancel).</p> + </li> + <li> + <p><strong>IndexedDB ist objektorientiert.</strong> IndexedDB ist keine relationale Datenbank, die Tabellen mit Sammlungen von Zeilen und Spalten hat. Dieser wichtige und grundlegende Unterschied beeinflusst die Art und Weise, wie Sie Ihre Anwendungen gestalten und bauen.<br> + <br> + In einem traditionellen relationalen Datenspeicher würden Sie Tabellen haben, in denen Sammlungen an Zeilen von Daten und Spalten von <em>named types</em> von Daten gespeichert wären. IndexedDB auf der anderen Seite erfordert es, dass Sie einen Objektspeicher für einen Datentyp erzeugen und einfach JavaScript-Objekte in diesem Speicher ablegen. Jeder Objektspeicher kann eine Sammlung an Indizes beinhalten, die es einfach machen zwischen ihnen zu suchen und zu iterieren. Wenn Sie nicht mit objektorientiertem Managementsystemen von Datenbanken vertraut sind, lesen Sie den <a class="external" href="https://de.wikipedia.org/wiki/Objektdatenbank" title="Objektdatenbank">Wikipedia-Artikel über Objektdatenbanken</a>.</p> + </li> + <li> + <p><strong>IndexedDB verwendet keine </strong><strong>Structured Query Language (<abbr>SQL</abbr>).</strong> Es verwendet Anfragen, die einen Positionsmarker erzeugen, den Sie verwenden um durch die Ergebnismenge zu iterieren. Wenn Sie nicht mit NoSQL-Systemen vertraut sind, lesen Sie den <a class="external" href="https://de.wikipedia.org/wiki/NoSQL" title="NoSQL">Wikipedia-Artikel zu NoSQL</a>.</p> + </li> + <li> + <p><a name="origin"><strong>IndexedDB hält an einer Same-Origin-Policy fest</strong></a>. Eine Herkunft (origin) besteht aus der Domain, dem Anwendungsschichtenprotokoll und dem Port einer URL des Dokuments, auf dem das Skript ausgeführt wird. Jede Herkunft hat ihre eigene entsprechende Untermenge an Datenbanken. Jede Datenbank hat einen Namen, das sie innerhalb einer Herkunft identifiziert.<br> + <br> + Die von IndexedDB auferlegte Sicherheitsbegrenzung hindert Anwendungen daran, auf Daten einer anderen Herkunft zuzugreifen. Während eine Anwendung oder eine Seite, die unter <a class="external" href="http://www.example.com/app/" rel="freelink">http://www.example.com/app/</a> liegt, Daten aus <a class="external" href="http://www.example.com/dir/" rel="freelink">http://www.example.com/dir/</a> abrufen kann, weil sie die gleiche Herkunft haben, kann sie nicht Daten aus <a class="external" href="http://www.example.com:8080/dir/" rel="freelink">http://www.example.com:8080/dir/</a> (anderer Port) oder <a class="link-https" href="https://www.example.com/dir/" rel="freelink">https://www.example.com/dir/</a> (anderes Protokoll) abrufen, weil sie verschiedene Herkünfte haben.</p> + </li> +</ul> +<h2 id="definitions" name="definitions">Definitionen</h2> +<p>Dieser Abschitt definiert und erklärt Begriffe, die in der IndexedDB-API verwendet werden.</p> +<h3 id="database" name="database">Datenbank</h3> +<dl> + <dt> + <a name="gloss_database">Datenbank</a></dt> + <dd> + Ein Aufbewahrungsort für Informationen, typischerweise bestehend aus einem oder mehreren <a href="#gloss_object_store" title="#gloss_object_store"><em>Objektspeichern</em></a>. Jede Datenbank muss folgende Angaben enthalten: + <ul> + <li>Name. Er identifiziert die Datenbank innerhalb einer konkreten Herkunft und verändert sich nicht innerhalb seiner Lebenszeit. Der Name kann aus einem beliebigen String-Wert bestehen (einschließlich dem leeren String).</li> + <li> + <p>Aktuelle <a href="#gloss_version"><em>Version</em></a>. Wenn eine Datenbank zum ersten Mal erstellt wird, nimmt ihre Version den integer-Wert 1 an, wenn nichts anderes angegeben wird. Jede Datenbank kann zu einem Zeitpunkt nur eine Version haben.</p> + </li> + </ul> + </dd> + <dt> + <a name="gloss_object_store">Objektspeicher</a></dt> + <dd> + <p>Das Instrument, mit welchem Daten in einer Datenbank gespeichert werden. Der Objektspeicher hält Eintragungen aus Schlüssel-Wert-Paaren permanent. Eintragungen innerhalb eines Objektspeichers werden entsprechend der <em><a href="#gloss_key">Schlüssel</a></em> in aufsteigender Reihenfolge sortiert.</p> + <p>Jeder Objektspeicher muss einen Namen haben, der innerhalb seiner Datenbank einzigartig ist. Der Objektspeicher kann optional einen <em><a href="#gloss_keygenerator">Schlüsselerzeuger</a></em> und einen <em><a href="#gloss_keypath">Schlüsselpfad</a></em> besitzen. Wenn der Objektspeicher einen Schlüsselpfad hat, verwendet er <em><a href="#gloss_inline_key">in-line keys</a></em>; ansonsten <em><a href="#gloss_outofline_key">out-of-line keys</a></em>.</p> + <p>Eine Referenzdokumentation zu Objektspeichern finden Sie unter <a href="../../../../en/IndexedDB/IDBObjectStore" rel="internal">IDBObjectStore</a> oder <a href="../../../../en/IndexedDB/IDBObjectStoreSync" rel="internal">IDBObjectStoreSync</a>.</p> + </dd> + <dt> + <a name="gloss_version">Version</a></dt> + <dd> + Wenn eine Datenbank zum ersten Mal erstellt wird, ist ihre Versionsnummer die integer-Zahl 1. Jede Datenbank hat zu jedem Zeitpunkt genau eine Versionsnummer; eine Datenbank kann nicht in verschiedenen Versionen gleichzeitig existieren. Die Versionsnummer kann nur geändert werden, indem die Datenbank mit einer größeren Versionsnummer geöffnet wird als mit der aktuellen. Das wird die <em>Transaktion</em> <code>versionchange</code> starten und ein <code>upgradeneeded</code> Ereignis auslösen. Die einzige Stelle, an der das Schema der Datenbank geupdatet werden kann, ist innerhalb des Handlers dieses Ereignisses.<br> + </dd> + <dd> + Anmerkung: Diese Definition beschreibt die <a class="external" href="http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html">aktuellsten Spezifikationen</a>, welche nur in Browsern auf dem neuesten Stand implementiert sind. In alten Browsern ist die mittlerweile veraltete und entfernte Methode <a href="/en-US/docs/IndexedDB/IDBDatabase#setVersion()" title="/en-US/docs/IndexedDB/IDBDatabase#setVersion()"><code>IDBDatabase.setVersion()</code></a> implementiert.</dd> + <dt> + <a name="gloss_database_connection">Datenbankverbindung</a></dt> + <dd> + Eine Operation, die beim Öffnen einer <em><a href="#gloss_database">Datenbank</a></em> erstellt wird. Eine vorgegebene Datenbank kann mehrere Verbindungen gleichzeitig haben.</dd> + <dt> + <a name="gloss_transaction">Transaktion</a></dt> + <dd> + <p>Eine nicht teilbare und dauerhafte Menge an Datenzugriffs- und Datenmodifikationsoperationen auf einer bestimmten Datenbank. Durch Transaktionen können Sie auf die Daten einer Datenbank zugreifen. Tatsächlich muss jeder Lese- oder Schreibvorgang von Daten in einer Transaktion stattfinden.<br> + <br> + Eine Datenbankverbindung kann mit mehreren aktiven Transaktionen gleichzeitig verknüpft sein, so lange schreibende Transaktionen keine überlappenden <a href="#gloss_scope"><em>scopes</em></a> haben. The scope of transactions, which is defined at creation, determines which object stores the transaction can interact with and remains constant for the lifetime of the transaction. So, for example, if a database connection already has a writing transaction with a scope that just covers the <code>flyingMonkey</code> object store, you can start a second transaction with a scope of the <code>unicornCentaur</code> and <code>unicornPegasus</code> object stores. As for reading transactions, you can have several of them—even overlapping ones.</p> + <p>Transactions are expected to be short-lived, so the browser can terminate a transaction that takes too long, in order to free up storage resources that the long-running transaction has locked. You can abort the transaction, which rolls back the changes made to the database in the transaction. And you don't even have to wait for the transaction to start or be active to abort it.</p> + <p>The three modes of transactions are: <code>readwrite</code>, <code>readonly</code>, and <code>versionchange</code>. The only way to create and delete object stores and indexes is by using a <code>versionchange</code> transaction. To learn more about transaction types, see the reference article for <a href="/de/docs/IndexedDB" title="https://developer.mozilla.org/en/IndexedDB">IndexedDB</a>.</p> + <p>Because everything happens within a transaction, it is a very important concept in IndexedDB. To learn more about transactions, especially on how they relate to versioning, see <a href="/en-US/docs/Web/API/IDBTransaction" rel="internal">IDBTransaction</a>, which also has reference documentation. For the documentation on the synchronous API, see <a href="/en-US/docs/Web/API/IDBTransactionSync" rel="internal">IDBTransactionSync</a>.</p> + </dd> + <dt> + <a name="gloss_request">Anfrage</a></dt> + <dd> + Die Operation, mit der Lese- und Schreibvorgänge auf einer Datenbank ausgeführt werden. Jede Anfrage repräsentiert eine Lese- oder Schreiboperation.</dd> + <dt> + <a name="gloss_index">Index</a></dt> + <dd> + <p>Ein Spezialobjektspeicher zum Nachschlagen von Einträgen eines anderen Objektspeichers, bezeichnet als <em>referenzierter Objektspeicher</em>. Der Index ist ein persistenter Schlüssel-Wert-Speicher, wobei der Wert seiner Einträge dem Schlüssel eines Eintrages im referenzierten Objektspeicher entspricht. Die Einträge in einem Index werden automatisch eingepflegt, sobald Einträge im referenzierten Objekt eingefügt, aktualisiert oder entfernt werden. Jeder Eintrag in einem Index kann auf nur einen Eintrag in seinem referenzierten Objektspeicher zeigen, aber mehrere Indizes können auf denselben Objektspeicher verweisen. Wenn der Objektspeicher sich ändert, werden alle Indizes, die auf ihn verweisen, automatisch aktualisiert.</p> + <p>Alternativ können Einträge eines Objektspeichers mithilfe eines <a href="#gloss_key">Schlüssels</a> nachgeschlagen werden.</p> + <p>Um mehr über die Verwendung von Indizes zu erfahren, lesen Sie <a href="/de/docs/IndexedDB/Using_IndexedDB#Using_an_index" title="en/IndexedDB/Using_IndexedDB#Using_an_index">Using IndexedDB</a>. Die Referenzdokumentation zu Indizes finden Sie unter <a href="/de/docs/Web/API/IDBKeyRange" rel="internal">IDBKeyRange</a>.</p> + </dd> +</dl> +<h3 id="key" name="key">Schlüssel und Wert</h3> +<dl> + <dt> + <a name="gloss_key">Schlüssel</a></dt> + <dd> + <p>Ein Datenwert über welchen abgelegte Werte aus dem Objektspeicher sortiert und ausgelesen werden können. Der Objektspeicher kann den Schlüssel aus einer dieser drei Quellen erlangen: Einem <em><a href="#gloss_keygenerator">Schlüsselgenerator</a></em>, einem <em><a href="#gloss_keypath">Schlüsselpfad</a></em> und einem explizit angegebem Wert. Der Schlüssel muss aus einem Datentyp bestehen, der eine Nummer hat, die größer ist als die des Schlüssel vor ihm. Jeder Eintrag in einem Objektspeicher muss einen innerhalb des gleichen Objektspeichers einzigartigen Schlüssel haben, deshalb können nicht mehrere Einträge mit demselben Schlüssel in einem vorgegebenem Objektspeicher vorliegen.<br> + <br> + Ein Schlüssel kann einen der folgenden Typen haben: <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/String" title="https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String">string</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Date" title="en/JavaScript/Reference/Global Objects/Date">date</a>, float und <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Array" title="en/JavaScript/Reference/Global Objects/Array">array</a>. Bei Arrays kann der Schlüssel zwischen einem leeren Wert und unendlich liegen. Arrays können wiederum Arrays beinhalten. Es gibt keine Vorschrift nur Schlüssel der Typen string oder integer zu verwenden {{ fx_minversion_inline("11") }}.</p> + <p>Alternativ können Sie Einträge eines Objektspeichers auch mithilfe eines <em><a href="#gloss_index">Index</a></em> nachschlagen.</p> + </dd> + <dt> + <a name="gloss_keygenerator">Schlüsselgenerator</a></dt> + <dd> + Ein Mechanismus um neue Schlüssel in einer angeordneten Reihenfolge zu erzeugen. Wenn ein Objektspeicher über keinen Schlüsselgenerator verfügt, muss die Anwendung Schlüssel für zu speichernde Einträge zur Verfügung stellen. Generatoren werden nicht zwischen Speichern geteilt. Dies ist mehr ein Detail von Browserimplementierungen, da in der Webentwicklung nicht wirklich Schlüsselgeneratoren erzeugt oder auf sie zugegriffen wird.</dd> + <dt> + <a name="gloss_inline_key">in-line key</a></dt> + <dd> + A key that is stored as part of the stored value. It is found using a <em>key path</em>. An in-line key can be generated using a generator. After the key has been generated, it can then be stored in the value using the key path or it can also be used as a key.</dd> + <dt> + <a name="gloss_outofline_key">out-of-line key</a></dt> + <dd> + A key that is stored separately from the value being stored.</dd> + <dt> + <a name="gloss_keypath">key path</a></dt> + <dd> + Defines where the browser should extract the key from a value in the object store or index. A valid key path can include one of the following: an empty string, a JavaScript identifier, or multiple JavaScript identifiers separated by periods. It cannot include spaces.</dd> + <dt> + <a name="gloss_value">value</a></dt> + <dd> + <p>Each record has a value, which could include anything that can be expressed in JavaScript, including: <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Boolean" rel="internal" title="en/JavaScript/Reference/Global_Objects/Boolean">boolean</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Number" rel="internal" title="en/JavaScript/Reference/Global_Objects/Number">number</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/String" title="https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String">string</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Date" title="en/JavaScript/Reference/Global Objects/Date">date</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Object" title="en/JavaScript/Reference/Global Objects/Object">object</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/Array" rel="internal" title="en/JavaScript/Reference/Global_Objects/Array">array</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/RegExp" rel="internal" title="en/JavaScript/Reference/Global_Objects/RegExp">regexp</a>, <a href="/de/docs/Web/JavaScript/Reference/Global_Objects/undefined" title="en/JavaScript/Reference/Global_Objects/undefined">undefined</a>, and null.</p> + <p>When an object or array is stored, the properties and values in that object or array can also be anything that is a valid value.</p> + <p><a href="/de/docs/Web/API/Blob" title="en/DOM/Blob">Blobs</a> and files can be stored, cf. <a class="external" href="http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html">specification</a> {{ fx_minversion_inline("11") }}.</p> + </dd> +</dl> +<h3 id="range" name="range">Range and scope</h3> +<dl> + <dt> + <a name="gloss_scope">scope</a></dt> + <dd> + The set of object stores and indexes to which a transaction applies. The scopes of read-only transactions can overlap and execute at the same time. On the other hand, the scopes of writing transactions cannot overlap. You can still start several transactions with the same scope at the same time, but they just queue up and execute one after another.</dd> + <dt> + <a name="gloss_cursor">cursor</a></dt> + <dd> + A mechanism for iterating over multiple records with a <em>key range</em>. The cursor has a source that indicates which index or object store it is iterating. It has a position within the range, and moves in a direction that is increasing or decreasing in the order of record keys. For the reference documentation on cursors, see <a href="/de/docs/Web/API/IDBCursor" rel="internal">IDBCursor</a> or <a href="/de/docs/Web/API/IDBCursorSync" rel="internal">IDBCursorSync</a>.</dd> + <dt> + <a name="gloss_key_range">key range</a></dt> + <dd> + <p>A continuous interval over some data type used for keys. Records can be retrieved from object stores and indexes using keys or a range of keys. You can limit or filter the range using lower and upper bounds. For example, you can iterate over all values of a key between x and y.</p> + <p>For the reference documentation on key range, see <a href="/de/docs/Web/API/IDBKeyRange" rel="internal">IDBKeyRange</a>.</p> + </dd> +</dl> +<h2 id="limitations" name="limitations">Limitations</h2> +<p>IndexedDB is designed to cover most cases that need client-side storage. However, it is not designed for a few cases like the following:</p> +<ul> + <li>Internationalized sorting. Not all languages sort strings in the same way, so internationalized sorting is not supported. While the database can't store data in a specific internationalized order, you can sort the data that you've read out of the database yourself.</li> + <li>Synchronizing. The API is not designed to take care of synchronizing with a server-side database. You have to write code that synchronizes a client-side indexedDB database with a server-side database.</li> + <li>Full text searching. The API<span style="direction: ltr;"> does not have an</span><span style="direction: ltr;"> equivalent of the <code>LIKE</code> operator in SQL. </span></li> +</ul> +<p>In addition, be aware that browsers can wipe out the database, such as in the following conditions:</p> +<ul> + <li>The user requests a wipe out.<br> + Many browsers have settings that let users wipe all data stored for a given website, including cookies, bookmarks, stored passwords, and IndexedDB data.</li> + <li>The browser is in private browsing mode.<br> + Some browsers, have "private browsing" (Firefox) or "incognito" (Chrome) modes. At the end of the session, the browser wipes out the database.</li> + <li>The disk or quota limit has been reached.</li> + <li>The data is corrupt.</li> + <li>An incompatible change is made to the feature.</li> +</ul> +<p>The exact circumstances and browser capabilities change over time, but the general philosophy of the browser vendors is to make the best effort to keep the data when possible.</p> +<div class="warning"> + <p><strong>Warning:</strong> At the moment due to bugs or on purpose it's impossible to open an IndexedDB database from a <a href="/de/docs/Accessibility/An_overview_of_accessible_web_applications_and_widgets" title="/en-US/docs/Accessibility/An_overview_of_accessible_web_applications_and_widgets">Web App</a>. This needs more investigation and then be documented.</p> +</div> +<h2 id="next" name="next">Next step</h2> +<p>OK, so, now with these big concepts under our belts, we can get to more concrete stuff. For a tutorial on how to use the API, see <a href="/de/docs/IndexedDB/Using_IndexedDB" title="en/IndexedDB/IndexedDB primer">Using IndexedDB</a>.</p> +<h2 id="See_also">See also</h2> +<p>Specification</p> +<ul> + <li><a href="http://www.w3.org/TR/IndexedDB/" title="http://www.w3.org/TR/IndexedDB/"><span style="direction: ltr;">Indexed Database API Specification</span></a></li> +</ul> +<p>Reference</p> +<ul> + <li><a href="/de/docs/IndexedDB" title="https://developer.mozilla.org/en/IndexedDB">IndexedDB API Reference</a></li> +</ul> +<p>Tutorials</p> +<ul> + <li><a href="/de/docs/IndexedDB/Using_IndexedDB" title="en/IndexedDB/IndexedDB primer">Using IndexedDB</a></li> + <li><a class="external" href="http://www.html5rocks.com/tutorials/indexeddb/todo/" title="http://www.html5rocks.com/tutorials/indexeddb/todo/">A simple TODO list using HTML5 IndexedDB</a><span class="external">. </span><span class="external"> {{ Note("This example uses an old version of the spec and does not work on up-to-date browsers - it still uses the removed <code>setVersion()</code> method.") }}</span></li> +</ul> +<p>Related article</p> +<ul> + <li><a class="external" href="http://msdn.microsoft.com/de-de/magazine/gg679063%28en-us%29.aspx" title="http://msdn.microsoft.com/en-us/scriptjunkie/gg679063.aspx">IndexedDB — The Store in Your Browser</a></li> +</ul> diff --git a/files/de/web/api/indexeddb_api/index.html b/files/de/web/api/indexeddb_api/index.html new file mode 100644 index 0000000000..171ca8a4c5 --- /dev/null +++ b/files/de/web/api/indexeddb_api/index.html @@ -0,0 +1,252 @@ +--- +title: IndexedDB +slug: Web/API/IndexedDB_API +tags: + - API + - Datenbank + - Einstieg + - IndexedDB + - NeedsTranslation + - Referenz + - Speicher + - TopicStub + - speichern +translation_of: Web/API/IndexedDB_API +--- +<div>{{DefaultAPISidebar("IndexedDB")}}</div> + +<p>IndexedDB ist eine low-level API für die clientseitige Speicherung großer Mengen strukturierter Daten einschließlich Dateien. Sie erlaubt auch Hochleistungssuchen dieser Daten durch die Verwendung von Indizes. Während der <a href="/de/docs/DOM/Storage" title="en-US/docs/DOM/Storage">DOM Speicher</a> nützlich zur Speicherung kleiner Datenmengen ist, ist er für größere Mengen strukturierte Daten wenig hilfreich. IndexedDB stellt hierfür eine Lösung bereit. Dies ist die Einstiegsseite der IndexedDB Referenz von MDN — hier stellen wir Links zur vollständigen API Referenz, Gebrauchsanleitungen, Unterstützungsdetails der Browser und einige Erklärungen des Schlüsselkonzepts zur Verfügung.</p> + +<p>{{AvailableInWorkers}}</p> + +<div class="note"> +<p><strong>Anmerkung</strong>: Die IndexedDB API ist leistungsfähig, kann aber für einfache Anwendungen zu kompliziert erscheinen. Wenn Du eine einfachere API bevorzugst, versuche Sammlungen wie <a href="https://localforage.github.io/localForage/">localForage</a> und <a href="http://www.dexie.org/">dexie.js</a>. Diese machen IndexedDB benutzerfreundlicher.</p> +</div> + +<div class="note"> +<p><strong>Anmerkung</strong>: Manche älteren Browser unterstützen IndexedDB nicht aber sie unterstützen <a href="http://caniuse.com/sql-storage"> WebSQL</a>. Eine Möglichkeit dieses Problem zu umgehen ist es, mittels polyfill auf <a href="http://www.w3.org/TR/webdatabase/">WebSQL</a> oder auch auf <a href="/de/docs/Web/Guide/API/DOM/Storage#localStorage">localStorage</a> für nicht unterstützende Browser zurückzugreifen. Das beste erhältiche polyfill ist derzeit <a href="https://localforage.github.io/localForage/">localForage</a>.</p> +</div> + +<h2 id="Schlüsselkonzepte_und_Gebrauch">Schlüsselkonzepte und Gebrauch</h2> + +<p>IndexedDB ist ein direktes Datenbank System, wie ein SQL-basiertes RDMS; während allerdings das Letztere Tabellen mit fixen Spalten benutzt, ist IndexedDB eine JavaScript-basierte objekt-orientierte Datenbank. IndexedDB läßt dich Objekte, die mit einem <strong>Schlüssel</strong> indiziert sind, speichern und wiederfinden. Jedes Objekt, das von einem <a href="/de/docs/Web/Guide/API/DOM/The_structured_clone_algorithm">strukturierten Klon Algorithmus</a> unterstützt wird, kann gespeichert werden. Du brauchst zum Beschreiben des Datenbankschemas eine offene Verbindung zu deiner Datenbank, dann kannst du Daten mit einer Reihe von Tranaktionen wiederfinden und aktualisieren.</p> + +<ul> + <li>Lies mehr über die <a href="/de/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB">Konzepte hinter IndexedDB</a>.</li> + <li>Nutze IndexedDB asynchron, indem du die Grundlagen mit unserer <a href="/de/docs/Web/API/IndexedDB_API/Using_IndexedDB">IndexedDB Anleitung</a> erlernst.</li> + <li>Finde Entwickler Empfehlungen, um Web Apps offline arbeiten zu lassen auf unserer <a href="/en-US/Apps/Build/Offline">Offline Apps</a> Seite</li> +</ul> + +<div class="note"> +<p><strong>Anmerkung</strong>: wie die meisten Web Speicher Lösungen folgt IndexedDB einem <a class="external" href="http://www.w3.org/Security/wiki/Same_Origin_Policy">gleicher-Ursprung Grundsatz</a>. Deshalb ist es nicht möglich auf Daten anderer Domänen zuzugreifen, während man auf gespeicherte Daten innerhalb einer Domäne zugreift.</p> +</div> + +<h3 id="Synchron_und_asynchron">Synchron und asynchron</h3> + +<p>Operationen unter Verwendung von IndexedDB werden asynchron durchgeführt, um Anwendungen nicht zu blockieren. IndexedDB beinhaltete ursprünglich eine asynchrone und eine synchrone API; die synchrone API war nur für den Gebrauch von <a href="/de/docs/Web/Guide/Performance/Using_web_workers">Web Workers</a> gedacht. Die synchrone Version wurde aus der Spezifikation entfernt, weil ihre Notwendigkeit fraglich war, aber sie kann in Zukunft wieder eingeführt werden, wenn es genug Nachfrage von Web Entwicklern gibt.</p> + +<h3 id="Speichergrenzen_und_Löschkriterien">Speichergrenzen und Löschkriterien</h3> + +<p>Es gibt mehrere Webtechnologien, um Daten auf die eine oder andere Art auf der Client Seite zu speichern (d. h. auf deiner lokalen Festplatte), über IndexedDB wird dabei am häufigsten geredet. Der Prozess mit dem der Browser herausfindet, wieviel Speicherplatz Webdaten zur Verfügung gestellt werden soll und was gelöscht werden soll, wenn die Grenze erreicht ist, ist nicht einfach und unterscheidet sich zwischen den Browsern. <a href="/de/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria">Browser Speichergrenzen und Löschkriterien</a> versuchen zu erklären, wie das geschieht - zumindest im Fall von Firefox.</p> + +<h2 id="IndexedDB_Schnittstellen">IndexedDB Schnittstellen</h2> + +<p>Um Zugang zu einer Datenbank zu erhalten, benutze <a href="/de/docs/Web/API/IDBFactory.open"><code>open()</code></a> von den <a href="/de/docs/Web/API/IDBEnvironment.indexedDB"><code>indexedDB</code></a> Attributen eines <a href="/de/docs/DOM/window">window</a> Objekts. Diese Methode gibt ein {{domxref("IDBRequest")}} Objekt zurück; asynchrone Operationen kommunizieren mit der aufrufenden Anwendung durch feuern von Events von {{domxref("IDBRequest")}} Objekten.</p> + +<h3 id="Mit_einer_Datenbank_verbinden">Mit einer Datenbank verbinden</h3> + +<dl> + <dt>{{domxref("IDBEnvironment")}}</dt> + <dd>Stellt den Zugang zur IndexedDB Funktionalität zur Verfügung. Es ist implementiert durch die {{domxref("window")}} und {{domxref("worker")}} Objekte.</dd> + <dt>{{domxref("IDBFactory")}}</dt> + <dd>Stellt den Zugang zu einer Datenbank bereit. Dies ist die durch das globale Objekt <a href="/en-US/docs/Web/API/IDBEnvironment.indexedDB"><code>indexedDB </code></a>bereitgestellte Schnittstelle und dadurch der Eingangspunkt für die API.</dd> + <dt>{{domxref("IDBOpenDBRequest")}}</dt> + <dd>Stellt eine Anfrage zum Öffnen einer Datenbank dar.</dd> + <dt>{{domxref("IDBDatabase")}}</dt> + <dd>Repräsentiert eine Verbindung zu einer Datenbank. Es ist der einzige Weg eine Transaktion in der Datenbank zu erreichen.</dd> +</dl> + +<dl> + <dt>{{domxref("IDBRequest")}}</dt> + <dd>Eine allgemeine Schnittstelle, die Datenbankabfragen behandelt und den Zugang zu Ergebnissen bereitstellt.</dd> +</dl> + +<h3 id="Abrufen_und_modifizieren_von_Daten">Abrufen und modifizieren von Daten</h3> + +<dl> + <dt>{{domxref("IDBTransaction")}}</dt> + <dd>Stellt eine Transaktion dar. Du erstellst eine Transaktion zu einer Datenbank, beschreibst den Geltungsbereich (beispielsweise auf welchen Objekt Speicher du zugreifen willst), und bestimmst die Art des Zugriffs (nur lesen oder lesen und schreiben), den du willst.</dd> + <dt>{{domxref("IDBObjectStore")}}</dt> + <dd>Steht für einen Objektspeicher, der Zugriff auf einen Datensatz in einer IndexedDB Datenbank erlaubt via Primärschlüsselsuche.</dd> + <dt>{{domxref("IDBIndex")}}</dt> + <dd>Gestattet ebenfalls Zugriff auf eine Teilmenge von Daten in einer IndexedDB Datenbank. Nutzt allerdings einen Index anstelle eines Primärschlüssels um an Einträge zu gelangen. Dies kann schneller sein als die Verwendung von {{domxref("IDBObjectStore")}}.</dd> + <dt>{{domxref("IDBCursor")}}</dt> + <dd>Iterates over object stores and indexes.</dd> + <dt>{{domxref("IDBCursorWithValue")}}</dt> + <dd>Iterates over object stores and indexes and returns the cursor's current value.</dd> + <dt>{{domxref("IDBKeyRange")}}</dt> + <dd>Defines a key range that can be used to retrieve data from a database in a certain range.</dd> + <dt>{{domxref("IDBLocaleAwareKeyRange")}} {{Non-standard_inline}}</dt> + <dd>Defines a key range that can be used to retrieve data from a database in a certain range, sorted acording to the rules of the locale specified for a certain index (see <a href="/en-US/docs/Web/API/IDBObjectStore/createIndex#Parameters"><code>createIndex()</code>'s optionalParameters</a>.).</dd> +</dl> + +<h3 id="Custom_event_interfaces">Custom event interfaces</h3> + +<p>This specification fires events with the following custom interface:</p> + +<dl> + <dt>{{domxref("IDBVersionChangeEvent")}}</dt> + <dd>The <code>IDBVersionChangeEvent</code> interface indicates that the version of the database has changed, as the result of an {{domxref("IDBOpenDBRequest.onupgradeneeded")}} event handler function.</dd> +</dl> + +<h3 id="Obsolete_interfaces">Obsolete interfaces</h3> + +<p>An early version of the specification also defined these now removed interfaces. They are still documented in case you need to update previously written code:</p> + +<dl> + <dt>{{domxref("IDBVersionChangeRequest")}} {{obsolete_inline}}</dt> + <dd>Represents a request to change the version of a database. The way to change the version of the database has since changed (by calling {{domxref("IDBFactory.open")}} without also calling {{domxref("IDBDatabase.setVersion")}}), and the interface {{domxref("IDBOpenDBRequest")}} now has the functionality of the removed {{domxref("IDBVersionChangeRequest")}}.</dd> + <dt>{{domxref("IDBDatabaseException")}} {{obsolete_inline}}</dt> + <dd>Represents exception conditions that can be encountered while performing database operations.</dd> + <dt>{{domxref("IDBTransactionSync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBTransaction")}}.</dd> + <dt>{{domxref("IDBObjectStoreSync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBObjectStore")}}.</dd> + <dt>{{domxref("IDBIndexSync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBIndex")}}.</dd> + <dt>{{domxref("IDBFactorySync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBFactory")}}.</dd> + <dt>{{domxref("IDBEnvironmentSync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBEnvironment")}}.</dd> + <dt>{{domxref("IDBDatabaseSync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBDatabase")}}.</dd> + <dt>{{domxref("IDBCursorSync")}} {{obsolete_inline}}</dt> + <dd>Sync version of {{domxref("IDBCursor")}}.</dd> +</dl> + +<h2 id="Examples">Examples</h2> + +<ul> + <li><a class="external" href="http://marco-c.github.io/eLibri/">eLibri:</a> A powerful library and eBook reader application, written by Marco Castelluccio, winner of the IndexedDB Mozilla DevDerby.</li> + <li><a class="external" href="https://github.com/chrisdavidmills/to-do-notifications/tree/gh-pages">To-do Notifications</a> (<a class="external" href="http://mdn.github.io/to-do-notifications/">view example live</a>): The reference application for the examples in the reference docs.</li> + <li><a class="external" href="http://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/">Storing images and files in IndexedDB</a></li> +</ul> + +<h2 id="Specifications">Specifications</h2> + +<table class="standard-table"> + <tbody> + <tr> + <th scope="col">Specification</th> + <th scope="col">Status</th> + <th scope="col">Comment</th> + </tr> + <tr> + <td>{{SpecName('IndexedDB', '#idl-def-IDBEnvironment', 'IDBEnvironment')}}</td> + <td>{{Spec2('IndexedDB')}}</td> + <td>Initial definition</td> + </tr> + </tbody> +</table> + +<h2 id="Browser_compatibility">Browser compatibility</h2> + +<p>{{CompatibilityTable}}</p> + +<div id="compat-desktop"> +<table class="compat-table"> + <tbody> + <tr> + <th>Feature</th> + <th>Chrome</th> + <th>Firefox (Gecko)</th> + <th>Internet Explorer</th> + <th>Opera</th> + <th>Safari (WebKit)</th> + </tr> + <tr> + <td>Basic support</td> + <td> + <p>23.0 {{property_prefix("webkit")}}<br> + 24</p> + </td> + <td>{{CompatGeckoDesktop("10.0")}} {{property_prefix("moz")}}<br> + {{CompatGeckoDesktop("16.0")}}</td> + <td>10, partial</td> + <td>15</td> + <td>7.1</td> + </tr> + <tr> + <td>Available in workers</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatGeckoDesktop("37.0")}}<sup>[1]</sup></td> + <td>{{CompatUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatUnknown}}</td> + </tr> + <tr> + <td><code>IDBLocaleAwareKeyRange</code></td> + <td>{{CompatNo}}</td> + <td>{{CompatGeckoDesktop("43.0")}}<sup>[2]</sup></td> + <td>{{CompatNo}}</td> + <td>{{CompatNo}}</td> + <td>{{CompatNo}}</td> + </tr> + </tbody> +</table> +</div> + +<div id="compat-mobile"> +<table class="compat-table"> + <tbody> + <tr> + <th>Feature</th> + <th>Android</th> + <th>Firefox Mobile (Gecko)</th> + <th>Firefox OS</th> + <th>IE Phone</th> + <th>Opera Mobile</th> + <th>Safari Mobile</th> + </tr> + <tr> + <td>Basic support</td> + <td>4.4</td> + <td>{{CompatGeckoMobile("22.0")}}</td> + <td>1.0.1</td> + <td>10</td> + <td>22</td> + <td>8</td> + </tr> + <tr> + <td>Available in workers</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatGeckoMobile("37.0")}}<sup>[1]</sup></td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatVersionUnknown}}</td> + <td>{{CompatUnknown}}</td> + </tr> + <tr> + <td><code>IDBLocaleAwareKeyRange</code></td> + <td>{{CompatNo}}</td> + <td>{{CompatGeckoMobile("43.0")}}<sup>[2]</sup></td> + <td>2.5<sup>[2]</sup></td> + <td>{{CompatNo}}</td> + <td>{{CompatNo}}</td> + <td>{{CompatNo}}</td> + </tr> + </tbody> +</table> +</div> + +<ul> + <li>[1] {{domxref("IDBCursorWithValue")}} is not available in workers until Gecko 42.0 {{geckoRelease("42.0")}}.</li> + <li>[2] This feature is currently hidden behind a flag — to enable it and experiment, go to about:config and enable dom.indexedDB.experimental.</li> +</ul> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a class="external" href="https://localforage.github.io/localForage/">localForage</a>: A Polyfill providing a simple name:value syntax for client-side data storage, which uses IndexedDB in the background, but falls back to WebSQL and then localStorage in browsers that don't support IndexedDB.</li> + <li><a class="external" href="http://www.dexie.org/">dexie.js</a>: A wrapper for IndexedDB that allows much faster code development via nice, simple syntax.</li> +</ul> diff --git a/files/de/web/api/indexeddb_api/indexeddb_verwenden/index.html b/files/de/web/api/indexeddb_api/indexeddb_verwenden/index.html new file mode 100644 index 0000000000..3d6d61cf3f --- /dev/null +++ b/files/de/web/api/indexeddb_api/indexeddb_verwenden/index.html @@ -0,0 +1,1180 @@ +--- +title: Verwendung von IndexedDB +slug: Web/API/IndexedDB_API/IndexedDB_verwenden +translation_of: Web/API/IndexedDB_API/Using_IndexedDB +--- +<p>Mit IndexedDB lassen sich Daten innerhalb des Browsers eines Benutzers permanent abzulegen. Es können so Webanwendungen mit funktionsreichen Abfragemöglichkeiten in Anwendungen erstellt werden, die sowohl online als auch offline funktionieren können, da keine Netzwerkfunktionalitäten benötigt werden.</p> + +<h2 id="Über_dieses_Dokument">Über dieses Dokument</h2> + +<p>Dieses Tutorial bespricht die Verwendung der asynchronen API von IndexedDB. Wenn Sie nicht mit IndexedDB vertraut sind, sollten Sie zuerst den Artikel <a href="/de/docs/IndexedDB/Grundkonzepte_hinter_IndexedDB" title="Grundkonzepte">Grundkonzepte</a> lesen.</p> + +<p>Eine Referenzdokumentation zur IndexedDB-API finden Sie im Artikel <a href="/de/docs/IndexedDB" title="IndexedDB">IndexedDB</a> und dessen Unterseiten, welche die Typen und Objekten dokumentieren, die von IndexedDB verwendet werden, ebenso wie die Methoden von sowohl synchronen als auch asynchronen APIs.</p> + +<h2 id="pattern" name="pattern">Grundschema</h2> + +<p>Das von IndexedDB unterstützte Grundschema sieht folgendermaßen aus:</p> + +<ol> + <li>Öffne eine Datenbank und starte eine Transaktion.</li> + <li>Erzeuge einen Objektspeicher.</li> + <li>Fordere die Ausführung von Datenbankoperationen an, wie das Hinzufügen und Auslesen von Daten.</li> + <li>Warte auf die richtige Art von DOM-Ereignis, das auftritt, wenn die Operation beendet ist.</li> + <li>Verarbeite die Ergebnisse? (, welche im Anforderungsobjekt gefunden werden können).</li> +</ol> + +<p>Mit dem Wissen über diese Grundkonzepte können wir uns nun konkreteren Dingen zuwenden.</p> + +<h2 id="open" name="open">Erzeugung und Strukturierung des Speichers</h2> + +<p>Weil sich die Spezifizierung noch in der Entwicklung befindet, verstecken sich aktuelle Implementierungen von IndexedDB unter Browserpräfixen. Bis sich die Spezifizierung verfestigt, könne Browserhersteller unterschiedliche Implementierungen der Standard-IndexedDB-API haben. Aber sobald Konsens auf dem Standard herrscht, implementieren die Hersteller ihn ohne Markierung durch Präfixe. Tatsächlich ist in manchen Implementierungen der Präfix entfernt: Internet Explorer 10, Firefox 16, Chrome 24. Wenn auf Gecko basierende Browser einen Präfix verwenden, dann verwenden sie den Präfix <code>moz</code>, während auf WebKit basierende Browser den Präfix <code>webkit</code> verwenden.</p> + +<h3 id="Verwendung_einer_experimentellen_Version_von_IndexedDB">Verwendung einer experimentellen Version von IndexedDB</h3> + +<p>Für den Fall, dass Sie Ihren Code in Browsern verwenden wollen, die noch Präfixe verwenden, können Sie folgenden Code benutzen:</p> + +<pre class="brush: js">// In der folgenden Zeile sollten Sie die Präfixe einfügen, die Sie testen wollen. +window.indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB; +// Verwenden Sie "var indexedDB = ..." NICHT außerhalb einer Funktion. +// Ferner benötigen Sie evtl. Referenzen zu einigen window.IDB* Objekten: +window.IDBTransaction = window.IDBTransaction || window.webkitIDBTransaction || window.msIDBTransaction; +window.IDBKeyRange = window.IDBKeyRange || window.webkitIDBKeyRange || window.msIDBKeyRange; +// (Mozilla hat diese Objekte nie mit Präfixen versehen, also brauchen wir kein window.mozIDB*)</pre> + +<p>Beachten Sie, dass Implementierungen, die Präfixe verwenden, fehlerhaft oder unvollständig sein können oder einer alten Version der Spezifizierung folgen können. Deshalb ist es nicht empfohlen, sie im Produktivsystem zu verwenden. In manchen Fällen kann es sinnvoll sein, lieber einen Browser nicht zu unterstützen als zu behaupten, er würde unterstützt, und dann Fehler einzubüßen:</p> + +<pre class="brush: js">if (!window.indexedDB) { + window.alert("Ihr Browser unterstützt keine stabile Version von IndexedDB. Dieses und jenes Feature wird Ihnen nicht zur Verfügung stehen."); +} +</pre> + +<h3 id="Öffnen_einer_Datenbank">Öffnen einer Datenbank</h3> + +<p>Wir starten den ganzen Prozess folgendermaßen:</p> + +<pre class="brush: js">// Öffnen unserer Datenbank +var request = window.indexedDB.open("MeineTestdatenbank", 3); +</pre> + +<p>Sie sehen, das Öffnen einer Datenbank funktioniert wie jede andere Operation – Sie müssen sie „anfordern“.</p> + +<p>Die Anforderung zum Öffnen öffnet nicht sofort die Datenbank und startet auch die Transaktion nicht gleich. Der Aufruf zur <code>open()</code> Funktion gibt ein <a href="/de/docs/Web/API/IDBOpenDBRequest" title="IDBOpenDBRequest"><code>IDBOpenDBRequest</code></a>-Objekt mit Ergebniswert (Erfolg) oder Fehlerwert zurück, die Sie als Ereignis verarbeiten. Die meisten anderen asynchronen Funktionen in IndexedDB machen das gleiche – sie geben ein <a href="/de/docs/Web/API/IDBRequest" title="IDBRequest"><code style="font-size: 14px; color: rgb(51, 51, 51);">IDBRequest</code></a>-Objekt mit Ergebnis oder Fehler zurück. Das Ergebnis für die open-Funktion ist eine Instanz einer <code style="font-size: 14px; color: rgb(51, 51, 51);"><a href="/de/docs/Web/API/IDBDatabase" title="IDBDatabase">IDBDatabase</a>.</code></p> + +<p>Der zweite Parameter der open-Methode ist die Version der Datenbank. Die Version der Datenbank bestimmt das Datenbankschema – den Objektspeichern und ihrer Strukturen. Wenn die angeforderte Version nicht existiert (weil die Datenbank neu ist, oder weil die Version aktualisiert wurde), wird das Ereignis <code>onupgradeneeded</code> ausgelöst, und es lässt sich eine neue Version der Datenbank im Handler für dieses Ereignis erzeugen. Mehr dazu später im Abschnitt <a href="#Updating_the_version_of_the_database">Aktualisieren der Version der Datenbank</a>.</p> + +<h4 id="Erzeugen_von_Handlern">Erzeugen von Handlern</h4> + +<p>Das erste, was Sie mit fast allen Anforderungen machen wollen, die Sie erzeugen, ist das Hinzufügen von Handlern für Erfolge und Fehler:</p> + +<pre class="brush: js">request.onerror = function(event) { + // Machen Sie etwas mit request.errorCode! +}; +request.onsuccess = function(event) { + // Machen Sie etwas mit request.result! +};</pre> + +<p>Welche der beiden Funktionen, <code>onsuccess()</code> oder <code>onerror()</code>, wird aufgerufen? Wenn alles fehlerfrei ablief, wird ein Erfolgsereignis (d.h. ein DOM-Ereignis, dessen <code>type</code> Eigenschaft auf <code>"success"</code> gesetzt ist) mit <code>request</code> als <code>target</code> ausgelöst. Sobald es ausgelöst wurde, wird die Funktion <code>onsuccess()</code> auf <code>request</code> ausgelöst mit dem Erfolgsereignis als Argument. Wenn nicht alles fehlerfrei ablief, wird ein Fehlerereignis (d.h. ein DOM-Ereignis, dessen <code>type</code> Eigenschaft auf <code>"error"</code> gesetzt ist) auf <code>request</code> ausgelöst. Dies löst die Funktion <code>onerror()</code> aus mit dem Fehlerereignis als Argument.</p> + +<p>Die IndexedDB-API ist so entworfen, dass sie die Notwendigkeit zur Fehlerbehandlung minimiert, also werden Sie wahrscheinlich nicht viele Fehlerereignisse sehen (zumindest nicht nachdem Sie sich an die API gewöhnt haben!). Beim Öffnen von Datenbanken jedoch gibt es ein paar typische Zustände, die Fehlerereignisse erzeugen. Das wahrscheinlichste Problem ist, dass der Benutzer festgelegt hat, den Webapps das Erzeugen von Datenbanken nicht zu erlauben. Eines der Hauptentwurfsziele von IndexedDB ist es, das Speichern von großen Datenmengen zur Offline-Verwendung zu erlauben. (Um mehr darüber zu erfahren, wieviel Speicher jedem Browser zur Verfügung steht, lesen Sie <a href="/de/docs/IndexedDB#Storage_limits" title="Storage_limits">Storage limits</a>).</p> + +<p>Offensichtlich wollen Browser nicht irgendeinem Werbenetzwerk oder einer böswilligen Website erlauben, Ihren Computer zu verschmutzen, deshalb warnen Browser den Benutzer, wenn eine Webapp zum ersten Mal versucht einen IndexedDB-Speicher zu öffnen. Der Benutzer kann wählen, ob er den Zugriff erlaubt oder verbietet. Außerdem ist IndexedDB komplett deaktiviert im Privaten Modus der Browser (Privater Modus für Firefox und Incognito Modus für Chrome). Der Hauptzweck vom Surfen im Privaten Modus ist es, keine Spuren zu hinterlassen, daher schlägt der Versuch fehl, eine Datenbank in diesem Modus zu öffnen.</p> + +<p>Nun nehmen wir an, dass der Benutzer Ihren Anfragen erlaubt hat, eine Datenbank zu erstellen, und Sie haben ein Erfolgsereignis erhalten, um den Erfolgs-Callback auszulösen; was kommt als nächstes? Die Anfrage wurde hier mit einem Aufruf von <code>indexedDB.open()</code> erzeugt, also ist <code>request.result</code> eine Instanz von <code>IDBDatabase</code>, und Sie wollen diese auf jeden Fall für später speichern. Ihr Code könnte etwa so aussehen:</p> + +<pre class="brush: js">var db; +var request = indexedDB.open("MeineTestdatenbank"); +request.onerror = function(event) { + alert("Warum haben Sie meiner Webapp nicht erlaubt IndexedDB zu verwenden?!"); +}; +request.onsuccess = function(event) { + db = request.result; +}; +</pre> + +<h4 id="Fehlerbehandlung">Fehlerbehandlung</h4> + +<p>Wie bereits oben erwähnt, werden Error events bei entsprechenden Fehlern ausgelöst und in der Objekthierarachie weiter nach oben gereicht. Solche Fehlerereignisse werden zunächst in der entsprechende Anfrage ausgelöst, die den Fehler verursacht hat. Anschließend werden sie zur Transaktion weitergereicht und schließlich zum Datenbankobjekt. Wenn man nicht für jede Anfrage einen Error-Handler schreiben möchte, kann man der Datenbank einen einzigen Error-Handler hinzufügen:</p> + +<pre class="brush: js">db.onerror = function(event) { + // Allgemeine Fehlerbehandlung, die für alle Anfragen an die Datenbank gilt. + alert("Datenbankfehler: " + event.target.errorCode); +}; +</pre> + +<p>Einer der häufigsten Fehler, die beim Öffnen der Datenbank auftreten, ist <code>VER_ERR</code>. Er zeigt an, dass die Versionsnummer der lokal gespeicherten Datenbank <em>größer </em> als die Versionsnummer ist, die man zu öffnen versucht. Ein solcher Fehler muss immer durch eine Fehlerbehandlung berücksichtigt werden.</p> + +<h3 id="Erstellen_oder_Updaten_der_Datenbank">Erstellen oder Updaten der Datenbank</h3> + +<p><a name="Updating_the_version_of_the_database"></a>Wenn eine neue Version der Datenbank erstellt wird, wird das <code style="font-style: normal; line-height: 1.5; color: rgb(51, 51, 51);">onupgradeneeded</code><span style="line-height: 1.5;"> Event ausgelöst. In der Handler-Funktion dieses Events musst du für die Erstellung der Datenbankspeicher, welche für diese Version benötigt wird, sorgen</span>:</p> + +<pre class="brush:js;">// Dieses Event ist lediglich in modernen Browsern verfügbar +request.onupgradeneeded = function(event) { + var db = event.target.result; + + // Erstelle ein ObjectStore für diese Datenbank + var objectStore = db.createObjectStore("name", { keyPath: "myKey" }); +};</pre> + +<p>The Versionsnummer der Datenbank ist vom Typ <code>unsigned long long</code>, so dass sie eine sehr große Ganzzahl sein kann.</p> + +<div class="warning"> +<p>Das Bedeutet auch, dass sie nicht vom Typ float sein darf, ansonsten wird sie zur nächstkleineren Ganzzahl abgerundet, so dass die Transaktion weder starten kann noch ein <code>upgradeneeded</code> ausgelöst wird. Beispielsweise sollte man nicht 2.4 als Versionsnummer verwenden:</p> + +<pre class="brush: js">var request = indexedDB.open("MeineTestdatenbank", 2.4); // don't do this, as the version will be rounded to 2</pre> +</div> + +<p>Wenn man die Versionsnummer der Datenbank erhöht, wird ein <code style="font-size: 14px; color: rgb(51, 51, 51);">onupgradeneeded</code><span style="line-height: 21px;"> </span> -Ereignis ausgelöst. In diesem Fall übernimmt die neue Datenbank automatisch die Objectstores von der Vorgängerversion der Datenbank, so dass man diese nicht erneut erzeugen muss. Lediglich neue Objectsores müssen angelegt oder nicht mehr gebrauchte der Vorgängerversion gelöscht werden. Wenn man einen bereits existierenden Objectstore ändern will (beispielsweise den keyPath veränden), ist es allerdings notwendig, den alten Objectstore zu löschen und einen neuen anzulegen. (Beachten Sie, dass dies die im Objectstore gespeicherten Informationen löscht, so dass man sie vorher auslesen und an anderer Stelle sichern sollte, bevor man ein Datenbankupgrade durchführt.)</p> + +<p>WebKit unterstützt die aktuelle Version dieser Spezifikation, wie sie in Chrome 23+ ausgeliefert wird, ebenso Opera 17+ und IE10+. Andere und ältere Implementierungen unterstützen nicht die aktuelle Version dieser Spezifikation und stellen damit auch noch nicht die Möglichkeit bereit, auf die Methodensignatur <code>indexedDB.open(name, version).onupgradeneeded</code> zugreifen zu könenn. Um ältere Versionen einer Datenbank auf neuer Versionen zu aktualisieren, siehe <a href="/en/IndexedDB/IDBDatabase#setVersion()_.0A.0ADeprecated" title="https://developer.mozilla.org/en/IndexedDB/IDBDatabase#setVersion()_.0A.0ADeprecated">IDBDatabase reference article</a>.</p> + +<h3 id="Strukturierung_der_Datenbank">Strukturierung der Datenbank</h3> + +<p>Im Folgenden wird gezeigt, wie man eine die Daten strukturiert. IndexedDB verwendet Objectstores anstatt Tabellen, wobei eine einzelne Datenbank viele verschiedene Objectsores enthalten kann. Jeglicher Wert im Objectstore ist einem bestimmten Schlüssel (key) zugeordnet. Es werden dabei unterschiedliche Arten von Schlüsseln verarbeitet, abhängig davon, ob der Objectstore einen <a href="/en/IndexedDB#gloss_key_path" title="https://developer.mozilla.org/en/IndexedDB#gloss_key_path">key path</a> oder einen <a href="/en/IndexedDB#gloss_key_generator" title="en/IndexedDB#gloss key generator">key generator</a> benutzt.</p> + +<p>Die folgende Tabelle gibt eine Übersicht über die bereitgestellten Arten von Schlüssseln.</p> + +<table class="standard-table"> + <thead> + <tr> + <th scope="col">Key Path</th> + <th scope="col">Key Generator</th> + <th scope="col">Beschreibung</th> + </tr> + </thead> + <tbody> + <tr> + <td>Nein</td> + <td>Nein</td> + <td>Dieser Objectstore kann Daten beliebigen Typs speichern, inklusive primitiven Typen wie Zahlen und Zeichenketten (Strings). Beim Hinzufügen von Werten muss ein separater Schlüssel angegeben werden.</td> + </tr> + <tr> + <td>Ja</td> + <td>Nein</td> + <td>Dieser Objectstore kann nur JavaScript-Objekte speichern. Die Objekte müssen ein Attribut haben, dass wie der key path benannt ist.</td> + </tr> + <tr> + <td>Nein</td> + <td>Ja</td> + <td>Dieser Objectstore kann Daten beliebigen Typs speichern. Beim Hinzufügen von Werten kann ein separater Schlüssel angegeben werden. Fehlt der Schlüssel, so wird er generiert.</td> + </tr> + <tr> + <td>Ja</td> + <td>Ja</td> + <td>Dieser Objectstore kann nur JavaScript-Objekte speichern. In der Regel wird der Schlüssel automatisch generiert und als gleichnamiges Attribut im Objekt gespeichert. Falls es jedoch bereits ein Attribut mit dem Namen gibt, so wird der Schlüssel nicht generiert, sondern der Wert des Attributes wird verwendet.</td> + </tr> + </tbody> +</table> + +<p>You can also create indices on any object store, provided the object store holds objects, not primitives. An index lets you look up the values stored in an object store using the value of a property of the stored object, rather than the object's key.</p> + +<p>Additionally, indexes have the ability to enforce simple constraints on the stored data. By setting the unique flag when creating the index, the index ensures that no two objects are stored with both having the same value for the index's key path. So, for example, if you have an object store which holds a set of people, and you want to ensure that no two people have the same email address, you can use an index with the unique flag set to enforce this.</p> + +<p>That may sound confusing, but this simple example should illustrate the concepts:</p> + +<pre class="brush: js">// This is what our customer data looks like. +const customerData = [ + { ssn: "444-44-4444", name: "Bill", age: 35, email: "bill@company.com" }, + { ssn: "555-55-5555", name: "Donna", age: 32, email: "donna@home.org" } +]; +const dbName = "the_name"; + +var request = indexedDB.open(dbName, 2); + +request.onerror = function(event) { + // Handle errors. +}; +request.onupgradeneeded = function(event) { + var db = event.target.result; + + // Create an objectStore to hold information about our customers. We're + // going to use "ssn" as our key path because it's guaranteed to be + // unique. + var objectStore = db.createObjectStore("customers", { keyPath: "ssn" }); + + // Create an index to search customers by name. We may have duplicates + // so we can't use a unique index. + objectStore.createIndex("name", "name", { unique: false }); + + // Create an index to search customers by email. We want to ensure that + // no two customers have the same email, so use a unique index. + objectStore.createIndex("email", "email", { unique: true }); + + // Store values in the newly created objectStore. + for (var i in customerData) { + objectStore.add(customerData[i]); + } +}; +</pre> + +<p>As mentioned previously, <code>onupgradeneeded</code> is the only place where you can alter the structure of the database. In it, you can create and delete object stores and build and remove indices.</p> + +<div>Object stores are created with a single call to <code>createObjectStore()</code>. The method takes a name of the store, and a parameter object. Even though the parameter object is optional, it is very important, because it lets you define important optional properties and refine the type of object store you want to create. In our case, we've asked for an object store named "customers" and defined a keyPath that is the property that makes an individual object in the store unique. That property in this example is "ssn" since a social security number is guaranteed to be unique. "ssn" must be present on every object that is stored in the objectStore.</div> + +<p>We've also asked for an index named "name" that looks at the <code>name</code> property of the stored objects. As with <code>createObjectStore()</code>, <code>createIndex()</code> takes an optional <code>options</code> object that refines the type of index that you want to create. Adding objects that don't have a <code>name</code> property still succeeds, but the object won't appear in the "name" index.</p> + +<p>We can now retrieve the stored customer objects using their <code>ssn</code> from the object store directly, or using their name by using the index. To learn how this is done, see the section on <a href="/en/IndexedDB/Using_IndexedDB#Using_an_index" title="Using IndexedDB#Using an index">using an index</a>.</p> + +<h2 id="Hinzufügen_und_löschen_von_Daten">Hinzufügen und löschen von Daten</h2> + +<p>Before you can do anything with your new database, you need to start a transaction. Transactions come from the database object, and you have to specify which object stores you want the transaction to span. Also, you need to decide if you're going to make changes to the database or if you just need to read from it. Although transactions have three modes (read-only, read/write, and versionchange), you're better off using a read-only transaction when you can, because they can run concurrently</p> + +<h3 id="Daten_zur_Datenbank_hinzufügen">Daten zur Datenbank hinzufügen</h3> + +<p>If you've just created a database, then you probably want to write to it. Here's what that looks like:</p> + +<pre class="brush:js;">var transaction = db.transaction(["customers"], "readwrite"); +// Note: Older experimental implementations use the deprecated constant IDBTransaction.READ_WRITE instead of "readwrite". +// In case you want to support such an implementation, you can just write: +// var transaction = db.transaction(["customers"], IDBTransaction.READ_WRITE);</pre> + +<p>The <code>transaction()</code> function takes two arguments (though one is optional) and returns a transaction object. The first argument is a list of object stores that the transaction will span. You can pass an empty array if you want the transaction to span all object stores, but don't do it because the spec says an empty array should generate an InvalidAccessError. If you don't specify anything for the second argument, you get a read-only transaction. Since you want to write to it here you need to pass the <code>"readwrite"</code> flag.</p> + +<p>Now that you have a transaction you need to understand its lifetime. Transactions are tied very closely to the event loop. If you make a transaction and return to the event loop without using it then the transaction will become inactive. The only way to keep the transaction active is to make a request on it. When the request is finished you'll get a DOM event and, assuming that the request succeeded, you'll have another opportunity to extend the transaction during that callback. If you return to the event loop without extending the transaction then it will become inactive, and so on. As long as there are pending requests the transaction remains active. Transaction lifetimes are really very simple but it might take a little time to get used to. A few more examples will help, too. If you start seeing <code>TRANSACTION_INACTIVE_ERR</code> error codes then you've messed something up.</p> + +<p>Transactions can receive DOM events of three different types: <code>error</code>, <code>abort</code>, and <code>complete</code>. We've talked about the way that <code>error</code> events bubble, so a transaction receives error events from any requests that are generated from it. A more subtle point here is that the default behavior of an error is to abort the transaction in which it occurred. Unless you handle the error by calling <code>preventDefault()</code> on the error event, the entire transaction is rolled back. This design forces you to think about and handle errors, but you can always add a catchall error handler to the database if fine grained error handling is too cumbersome. If you don't handle an error event or if you call <code>abort()</code> on the transaction, then the transaction is rolled back and an <code>abort</code> event is fired on the transaction. Otherwise, after all pending requests have completed, you'll get a <code>complete</code> event. If you're doing lots of database operations, then tracking the transaction rather than individual requests can certainly aide your sanity.</p> + +<p>Now that you have a transaction, you'll need to get the object store from it. Transactions only let you have an object store that you specified when creating the transaction. Then you can add all the data you need.</p> + +<pre class="brush: js">// Do something when all the data is added to the database. +transaction.oncomplete = function(event) { + alert("All done!"); +}; + +transaction.onerror = function(event) { + // Don't forget to handle errors! +}; + +var objectStore = transaction.objectStore("customers"); +for (var i in customerData) { + var request = objectStore.add(customerData[i]); + request.onsuccess = function(event) { + // event.target.result == customerData[i].ssn; + }; +}</pre> + +<p>The <code>result</code> of a request generated from a call to <code>add() </code>is the key of the value that was added. So in this case, it should equal the <code>ssn</code> property of the object that was added, since the object store uses the <code>ssn</code> property for the key path. Note that the <code>add()</code> function requires that no object already be in the database with the same key. If you're trying to modify an existing entry, or you don't care if one exists already, use the <code>put()</code> function.</p> + +<h2 id="Daten_aus_der_Datenbank_löschen">Daten aus der Datenbank löschen</h2> + +<p>Löschen von Daten ist recht ähnlich:</p> + +<pre class="brush: js">var request = db.transaction(["customers"], "readwrite") + .objectStore("customers") + .delete("444-44-4444"); +request.onsuccess = function(event) { + // It's gone! +};</pre> + +<h2 id="Daten_aus_der_Datenbank_auslesen">Daten aus der Datenbank auslesen</h2> + +<p>Now that the database has some info in it, you can retrieve it in several ways. First, the simple <code>get()</code>. You need to provide the key to retrieve the value, like so:</p> + +<pre class="brush: js">var transaction = db.transaction(["customers"]); +var objectStore = transaction.objectStore("customers"); +var request = objectStore.get("444-44-4444"); +request.onerror = function(event) { + // Handle errors! +}; +request.onsuccess = function(event) { + // Do something with the request.result! + alert("Name for SSN 444-44-4444 is " + request.result.name); +};</pre> + +<p>That's a lot of code for a "simple" retrieval. Here's how you can shorten it up a bit, assuming that you handle errors at the database level:</p> + +<pre class="brush: js">db.transaction("customers").objectStore("customers").get("444-44-4444").onsuccess = function(event) { + alert("Name for SSN 444-44-4444 is " + event.target.result.name); +};</pre> + +<p>See how this works? Since there's only one object store, you can avoid passing a list of object stores you need in your transaction and just pass the name as a string. Also, you're only reading from the database, so you don't need a <code>"readwrite"</code> transaction. Calling <code>transaction()</code> with no mode specified gives you a <code>"readonly"</code> transaction. Another subtlety here is that you don't actually save the request object to a variable. Since the DOM event has the request as its target you can use the event to get to the <code>result</code> property. Easy, right?!</p> + +<h2 id="Benutzung_eines_Cursors">Benutzung eines Cursors</h2> + +<p>Using <code>get()</code> requires that you know which key you want to retrieve. If you want to step through all the values in your object store, then you can use a cursor. Here's what it looks like:</p> + +<pre class="brush: js">var objectStore = db.transaction("customers").objectStore("customers"); + +objectStore.openCursor().onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + alert("Name for SSN " + cursor.key + " is " + cursor.value.name); + cursor.continue(); + } + else { + alert("No more entries!"); + } +};</pre> + +<p>The<code> openCursor()</code> function takes several arguments. First, you can limit the range of items that are retrieved by using a key range object that we'll get to in a minute. Second, you can specify the direction that you want to iterate. In the above example, we're iterating over all objects in ascending order. The success callback for cursors is a little special. The cursor object itself is the <code>result</code> of the request (above we're using the shorthand, so it's <code>event.target.result</code>). Then the actual key and value can be found on the <code>key</code> and <code>value</code> properties of the cursor object. If you want to keep going, then you have to call <code>continue()</code> on the cursor. When you've reached the end of the data (or if there were no entries that matched your <code>openCursor()</code> request) you still get a success callback, but the <code>result</code> property is <code>undefined</code>.</p> + +<p>One common pattern with cursors is to retrieve all objects in an object store and add them to an array, like this:</p> + +<pre class="brush: js">var customers = []; + +objectStore.openCursor().onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + customers.push(cursor.value); + cursor.continue(); + } + else { + alert("Got all customers: " + customers); + } +};</pre> + +<div class="warning"><strong>Warnung:</strong> Die folgende Funktion ist nicht Teil des IndexedDB Standards.</div> + +<p>Mozilla has also implemented <code>getAll()</code> to handle this case. It isn't part of the IndexedDB standard, so it may disappear in the future. We've included it because we think it's useful. The following code does precisely the same thing as above:</p> + +<pre class="brush: js">objectStore.getAll().onsuccess = function(event) { + alert("Got all customers: " + event.target.result); +};</pre> + +<p>There is a performance cost associated with looking at the <code>value</code> property of a cursor, because the object is created lazily. When you use <code>getAll()</code>, Gecko must create all the objects at once. If you're just interested in looking at each of the keys, for instance, it is much more efficient to use a cursor than to use <code>getAll()</code>. If you're trying to get an array of all the objects in an object store, though, use <code>getAll()</code>.</p> + +<h3 id="Benutzung_eines_Index">Benutzung eines Index</h3> + +<p>Storing customer data using the SSN as a key is logical since the SSN uniquely identifies an individual. (Whether this is a good idea for privacy is a different question, outside the scope of this article.) If you need to look up a customer by name, however, you'll need to iterate over every SSN in the database until you find the right one. Searching in this fashion would be very slow, so instead you can use an index.</p> + +<pre class="brush: js">var index = objectStore.index("name"); +index.get("Donna").onsuccess = function(event) { + alert("Donna's SSN is " + event.target.result.ssn); +};</pre> + +<p>The "name" cursor isn't unique, so there could be more than one entry with the <code>name</code> set to <code>"Donna"</code>. In that case you always get the one with the lowest key value.</p> + +<p>If you need to access all the entries with a given <code>name</code> you can use a cursor. You can open two different types of cursors on indexes. A normal cursor maps the index property to the object in the object store. A key cursor maps the index property to the key used to store the object in the object store. The differences are illustrated here:</p> + +<pre class="brush: js">index.openCursor().onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + // cursor.key is a name, like "Bill", and cursor.value is the whole object. + alert("Name: " + cursor.key + ", SSN: " + cursor.value.ssn + ", email: " + cursor.value.email); + cursor.continue(); + } +}; + +index.openKeyCursor().onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + // cursor.key is a name, like "Bill", and cursor.value is the SSN. + // No way to directly get the rest of the stored object. + alert("Name: " + cursor.key + ", SSN: " + cursor.value); + cursor.continue(); + } +};</pre> + +<h3 id="Specifying_the_range_and_direction_of_cursors">Specifying the range and direction of cursors</h3> + +<p>If you would like to limit the range of values you see in a cursor, you can use a key range object and pass it as the first argument to <code>openCursor()</code> or <code>openKeyCursor()</code>. You can make a key range that only allows a single key, or one the has a lower or upper bound, or one that has both a lower and upper bound. The bound may be "closed" (i.e., the key range includes the given value) or "open" (i.e., the key range does not include the given value). Here's how it works:</p> + +<pre class="brush: js">// Only match "Donna" +var singleKeyRange = IDBKeyRange.only("Donna"); + +// Match anything past "Bill", including "Bill" +var lowerBoundKeyRange = IDBKeyRange.lowerBound("Bill"); + +// Match anything past "Bill", but don't include "Bill" +var lowerBoundOpenKeyRange = IDBKeyRange.lowerBound("Bill", true); + +// Match anything up to, but not including, "Donna" +var upperBoundOpenKeyRange = IDBKeyRange.upperBound("Donna", true); + +//Match anything between "Bill" and "Donna", but not including "Donna" +var boundKeyRange = IDBKeyRange.bound("Bill", "Donna", false, true); + +index.openCursor(boundKeyRange).onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + // Do something with the matches. + cursor.continue(); + } +};</pre> + +<p>Sometimes you may want to iterate in descending order rather than in ascending order (the default direction for all cursors). Switching direction is accomplished by passing <code>prev</code> to the <code>openCursor()</code> function:</p> + +<pre class="brush: js">objectStore.openCursor(null, IDBCursor.prev).onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + // Do something with the entries. + cursor.continue(); + } +};</pre> + +<p>Since the "name" index isn't unique, there might be multiple entries where <code>name</code> is the same. Note that such a situation cannot occur with object stores since the key must always be unique. If you wish to filter out duplicates during cursor iteration over indexes, you can pass <code>nextunique</code> (or <code>prevunique</code> if you're going backwards) as the direction parameter. When <code>nextunique</code> or <code>prevunique</code> is used, the entry with the lowest key is always the one returned.</p> + +<pre class="brush: js">index.openKeyCursor(null, IDBCursor.nextunique).onsuccess = function(event) { + var cursor = event.target.result; + if (cursor) { + // Do something with the entries. + cursor.continue(); + } +};</pre> + +<h2 id="Versionsänderung_während_eine_Webapplikation_in_einem_anderen_Tab_geöffnet_ist">Versionsänderung während eine Webapplikation in einem anderen Tab geöffnet ist</h2> + +<p>When your web app changes in such a way that a version change is required for your database, you need to consider what happens if the user has the old version of your app open in one tab and then loads the new version of your app in another. When you call <code>open()</code> with a greater version than the actual version of the database, all other open databases must explicitly acknowledge the request before you can start making changes to the database. Here's how it works:</p> + +<pre class="brush: js">var openReq = mozIndexedDB.open("MyTestDatabase", 2); + +openReq.onblocked = function(event) { + // If some other tab is loaded with the database, then it needs to be closed + // before we can proceed. + alert("Please close all other tabs with this site open!"); +}; + +openReq.onupgradeneeded = function(event) { + // All other databases have been closed. Set everything up. + db.createObjectStore(/* ... */); + useDatabase(db); +} + +openReq.onsuccess = function(event) { + var db = event.target.result; + useDatabase(db); + return; +} + +function useDatabase(db) { + // Make sure to add a handler to be notified if another page requests a version + // change. We must close the database. This allows the other page to upgrade the database. + // If you don't do this then the upgrade won't happen until the user close the tab. + db.onversionchange = function(event) { + db.close(); + alert("A new version of this page is ready. Please reload!"); + }; + + // Do stuff with the database. +} +</pre> + +<h2 id="Sicherheit">Sicherheit</h2> + +<p>IndexedDB uses the same-origin principle, which means that it ties the store to the origin of the site that creates it (typically, this is the site domain or subdomain), so it cannot be accessed by any other origin.</p> + +<p>It's important to note that IndexedDB doesn't work for content loaded into a frame from another site (either {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. This is a security measure. Details as to why this matters are forthcoming. See {{ bug(595307) }}.</p> + +<h2 id="Warnung_über_die_Schließung_des_Browsers">Warnung über die Schließung des Browsers</h2> + +<p>When the browser shuts down (e.g., when the user selects Exit or clicks the Close button), any pending IndexedDB transactions are (silently) aborted -- they will not complete, and they will not trigger the error handler. Since the user can exit the browser at any time, this means that you cannot rely upon any particular transaction to complete or to know that it did not complete. There are several implications of this behavior.</p> + +<p>First, you should take care to always leave your database in a consistent state at the end of every transaction. For example, suppose that you are using IndexedDB to store a list of items that you allow the user to edit. You save the list after the edit by clearing the object store and then writing out the new list. If you clear the object store in one transaction and write the new list in another transaction, there is a danger that the browser will close after the clear but before the write, leaving you with an empty database. To avoid this, you should combine the clear and the write into a single transaction.</p> + +<p>Second, you should never tie database transactions to unload events. If the unload event is triggered by the browser closing, any transactions created in the unload event handler will never complete. An intuitive approach to maintaining some information across browser sessions is to read it from the database when the browser (or a particular page) is opened, update it as the user interacts with the browser, and then save it to the database when the browser (or page) closes. However, this will not work. The database transactions will be created in the unload event handler, but because they are asynchronous they will be aborted before they can execute.</p> + +<p>In fact, there is no way to guarantee that IndexedDB transactions will complete, even with normal browser shutdown. See {{ bug(870645) }}.</p> + +<h2 id="Full_IndexedDB_example" name="Full_IndexedDB_example">Vollständiges IndexedDB Beispiel</h2> + +<h3 id="HTML_Content">HTML Content</h3> + +<pre class="brush: html"><script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script> + + <h1>IndexedDB Demo: storing blobs, e-publication example</h1> + <div class="note"> + <p> + Works and tested with: + </p> + <div id="compat"> + </div> + </div> + + <div id="msg"> + </div> + + <form id="register-form"> + <table> + <tbody> + <tr> + <td> + <label for="pub-title" class="required"> + Title: + </label> + </td> + <td> + <input type="text" id="pub-title" name="pub-title" /> + </td> + </tr> + <tr> + <td> + <label for="pub-biblioid" class="required"> + Bibliographic ID:<br/> + <span class="note">(ISBN, ISSN, etc.)</span> + </label> + </td> + <td> + <input type="text" id="pub-biblioid" name="pub-biblioid"/> + </td> + </tr> + <tr> + <td> + <label for="pub-year"> + Year: + </label> + </td> + <td> + <input type="number" id="pub-year" name="pub-year" /> + </td> + </tr> + </tbody> + <tbody> + <tr> + <td> + <label for="pub-file"> + File image: + </label> + </td> + <td> + <input type="file" id="pub-file"/> + </td> + </tr> + <tr> + <td> + <label for="pub-file-url"> + Online-file image URL:<br/> + <span class="note">(same origin URL)</span> + </label> + </td> + <td> + <input type="text" id="pub-file-url" name="pub-file-url"/> + </td> + </tr> + </tbody> + </table> + + <div class="button-pane"> + <input type="button" id="add-button" value="Add Publication" /> + <input type="reset" id="register-form-reset"/> + </div> + </form> + + <form id="delete-form"> + <table> + <tbody> + <tr> + <td> + <label for="pub-biblioid-to-delete"> + Bibliographic ID:<br/> + <span class="note">(ISBN, ISSN, etc.)</span> + </label> + </td> + <td> + <input type="text" id="pub-biblioid-to-delete" + name="pub-biblioid-to-delete" /> + </td> + </tr> + <tr> + <td> + <label for="key-to-delete"> + Key:<br/> + <span class="note">(for example 1, 2, 3, etc.)</span> + </label> + </td> + <td> + <input type="text" id="key-to-delete" + name="key-to-delete" /> + </td> + </tr> + </tbody> + </table> + <div class="button-pane"> + <input type="button" id="delete-button" value="Delete Publication" /> + <input type="button" id="clear-store-button" + value="Clear the whole store" class="destructive" /> + </div> + </form> + + <form id="search-form"> + <div class="button-pane"> + <input type="button" id="search-list-button" + value="List database content" /> + </div> + </form> + + <div> + <div id="pub-msg"> + </div> + <div id="pub-viewer"> + </div> + <ul id="pub-list"> + </ul> + </div> +</pre> + +<h3 id="CSS_Content">CSS Content</h3> + +<pre class="brush: css">body { + font-size: 0.8em; + font-family: Sans-Serif; +} + +form { + background-color: #cccccc; + border-radius: 0.3em; + display: inline-block; + margin-bottom: 0.5em; + padding: 1em; +} + +table { + border-collapse: collapse; +} + +input { + padding: 0.3em; + border-color: #cccccc; + border-radius: 0.3em; +} + +.required:after { + content: "*"; + color: red; +} + +.button-pane { + margin-top: 1em; +} + +#pub-viewer { + float: right; + width: 48%; + height: 20em; + border: solid #d092ff 0.1em; +} +#pub-viewer iframe { + width: 100%; + height: 100%; +} + +#pub-list { + width: 46%; + background-color: #eeeeee; + border-radius: 0.3em; +} +#pub-list li { + padding-top: 0.5em; + padding-bottom: 0.5em; + padding-right: 0.5em; +} + +#msg { + margin-bottom: 1em; +} + +.action-success { + padding: 0.5em; + color: #00d21e; + background-color: #eeeeee; + border-radius: 0.2em; +} + +.action-failure { + padding: 0.5em; + color: #ff1408; + background-color: #eeeeee; + border-radius: 0.2em; +} + +.note { + font-size: smaller; +} + +.destructive { + background-color: orange; +} +.destructive:hover { + background-color: #ff8000; +} +.destructive:active { + background-color: red; +} +</pre> + +<p> </p> + +<h3 id="JavaScript_Content">JavaScript Content</h3> + +<pre class="brush: js">(function () { + var COMPAT_ENVS = [ + ['Firefox', ">= 16.0"], + ['Google Chrome', + ">= 24.0 (you may need to get Google Chrome Canary), NO Blob storage support"] + ]; + var compat = $('#compat'); + compat.empty(); + compat.append('<ul id="compat-list"></ul>'); + COMPAT_ENVS.forEach(function(val, idx, array) { + $('#compat-list').append('<li>' + val[0] + ': ' + val[1] + '</li>'); + }); + + const DB_NAME = 'mdn-demo-indexeddb-epublications'; + const DB_VERSION = 1; // Use a long long for this value (don't use a float) + const DB_STORE_NAME = 'publications'; + + var db; + + // Used to keep track of which view is displayed to avoid to uselessly reload it + var current_view_pub_key; + + function openDb() { + console.log("openDb ..."); + var req = indexedDB.open(DB_NAME, DB_VERSION); + req.onsuccess = function (evt) { + // Better use "this" than "req" to get the result to avoid problems with + // garbage collection. + // db = req.result; + db = this.result; + console.log("openDb DONE"); + }; + req.onerror = function (evt) { + console.error("openDb:", evt.target.errorCode); + }; + + req.onupgradeneeded = function (evt) { + console.log("openDb.onupgradeneeded"); + var store = evt.currentTarget.result.createObjectStore( + DB_STORE_NAME, { keyPath: 'id', autoIncrement: true }); + + store.createIndex('biblioid', 'biblioid', { unique: true }); + store.createIndex('title', 'title', { unique: false }); + store.createIndex('year', 'year', { unique: false }); + }; + } + + /** + * @param {string} store_name + * @param {string} mode either "readonly" or "readwrite" + */ + function getObjectStore(store_name, mode) { + var tx = db.transaction(store_name, mode); + return tx.objectStore(store_name); + } + + function clearObjectStore(store_name) { + var store = getObjectStore(DB_STORE_NAME, 'readwrite'); + var req = store.clear(); + req.onsuccess = function(evt) { + displayActionSuccess("Store cleared"); + displayPubList(store); + }; + req.onerror = function (evt) { + console.error("clearObjectStore:", evt.target.errorCode); + displayActionFailure(this.error); + }; + } + + function getBlob(key, store, success_callback) { + var req = store.get(key); + req.onsuccess = function(evt) { + var value = evt.target.result; + if (value) + success_callback(value.blob); + }; + } + + /** + * @param {IDBObjectStore=} store + */ + function displayPubList(store) { + console.log("displayPubList"); + + if (typeof store == 'undefined') + store = getObjectStore(DB_STORE_NAME, 'readonly'); + + var pub_msg = $('#pub-msg'); + pub_msg.empty(); + var pub_list = $('#pub-list'); + pub_list.empty(); + // Reseting the iframe so that it doesn't display previous content + newViewerFrame(); + + var req; + req = store.count(); + // Requests are executed in the order in which they were made against the + // transaction, and their results are returned in the same order. + // Thus the count text below will be displayed before the actual pub list + // (not that it is algorithmically important in this case). + req.onsuccess = function(evt) { + pub_msg.append('<p>There are <strong>' + evt.target.result + + '</strong> record(s) in the object store.</p>'); + }; + req.onerror = function(evt) { + console.error("add error", this.error); + displayActionFailure(this.error); + }; + + var i = 0; + req = store.openCursor(); + req.onsuccess = function(evt) { + var cursor = evt.target.result; + + // If the cursor is pointing at something, ask for the data + if (cursor) { + console.log("displayPubList cursor:", cursor); + req = store.get(cursor.key); + req.onsuccess = function (evt) { + var value = evt.target.result; + var list_item = $('<li>' + + '[' + cursor.key + '] ' + + '(biblioid: ' + value.biblioid + ') ' + + value.title + + '</li>'); + if (value.year != null) + list_item.append(' - ' + value.year); + + if (value.hasOwnProperty('blob') && + typeof value.blob != 'undefined') { + var link = $('<a href="' + cursor.key + '">File</a>'); + link.on('click', function() { return false; }); + link.on('mouseenter', function(evt) { + setInViewer(evt.target.getAttribute('href')); }); + list_item.append(' / '); + list_item.append(link); + } else { + list_item.append(" / No attached file"); + } + pub_list.append(list_item); + }; + + // Move on to the next object in store + cursor.continue(); + + // This counter serves only to create distinct ids + i++; + } else { + console.log("No more entries"); + } + }; + } + + function newViewerFrame() { + var viewer = $('#pub-viewer'); + viewer.empty(); + var iframe = $('<iframe />'); + viewer.append(iframe); + return iframe; + } + + function setInViewer(key) { + console.log("setInViewer:", arguments); + key = Number(key); + if (key == current_view_pub_key) + return; + + current_view_pub_key = key; + + var store = getObjectStore(DB_STORE_NAME, 'readonly'); + getBlob(key, store, function(blob) { + console.log("setInViewer blob:", blob); + var iframe = newViewerFrame(); + + // It is not possible to set a direct link to the + // blob to provide a mean to directly download it. + if (blob.type == 'text/html') { + var reader = new FileReader(); + reader.onload = (function(evt) { + var html = evt.target.result; + iframe.load(function() { + $(this).contents().find('html').html(html); + }); + }); + reader.readAsText(blob); + } else if (blob.type.indexOf('image/') == 0) { + iframe.load(function() { + var img_id = 'image-' + key; + var img = $('<img id="' + img_id + '"/>'); + $(this).contents().find('body').html(img); + var obj_url = window.URL.createObjectURL(blob); + $(this).contents().find('#' + img_id).attr('src', obj_url); + window.URL.revokeObjectURL(obj_url); + }); + } else if (blob.type == 'application/pdf') { + $('*').css('cursor', 'wait'); + var obj_url = window.URL.createObjectURL(blob); + iframe.load(function() { + $('*').css('cursor', 'auto'); + }); + iframe.attr('src', obj_url); + window.URL.revokeObjectURL(obj_url); + } else { + iframe.load(function() { + $(this).contents().find('body').html("No view available"); + }); + } + + }); + } + + /** + * @param {string} biblioid + * @param {string} title + * @param {number} year + * @param {string} url the URL of the image to download and store in the local + * IndexedDB database. The resource behind this URL is subjected to the + * "Same origin policy", thus for this method to work, the URL must come from + * the same origin than the web site/app this code is deployed on. + */ + function addPublicationFromUrl(biblioid, title, year, url) { + console.log("addPublicationFromUrl:", arguments); + + var xhr = new XMLHttpRequest(); + xhr.open('GET', url, true); + // Setting the wanted responseType to "blob" + // http://www.w3.org/TR/XMLHttpRequest2/#the-response-attribute + xhr.responseType = 'blob'; + xhr.onload = function (evt) { + if (xhr.status == 200) { + console.log("Blob retrieved"); + var blob = xhr.response; + console.log("Blob:", blob); + addPublication(biblioid, title, year, blob); + } else { + console.error("addPublicationFromUrl error:", + xhr.responseText, xhr.status); + } + }; + xhr.send(); + + // We can't use jQuery here because as of jQuery 1.8.3 the new "blob" + // responseType is not handled. + // http://bugs.jquery.com/ticket/11461 + // http://bugs.jquery.com/ticket/7248 + // $.ajax({ + // url: url, + // type: 'GET', + // xhrFields: { responseType: 'blob' }, + // success: function(data, textStatus, jqXHR) { + // console.log("Blob retrieved"); + // console.log("Blob:", data); + // // addPublication(biblioid, title, year, data); + // }, + // error: function(jqXHR, textStatus, errorThrown) { + // console.error(errorThrown); + // displayActionFailure("Error during blob retrieval"); + // } + // }); + } + + /** + * @param {string} biblioid + * @param {string} title + * @param {number} year + * @param {Blob=} blob + */ + function addPublication(biblioid, title, year, blob) { + console.log("addPublication arguments:", arguments); + var obj = { biblioid: biblioid, title: title, year: year }; + if (typeof blob != 'undefined') + obj.blob = blob; + + var store = getObjectStore(DB_STORE_NAME, 'readwrite'); + var req; + try { + req = store.add(obj); + } catch (e) { + if (e.name == 'DataCloneError') + displayActionFailure("This engine doesn't know how to clone a Blob, " + + "use Firefox"); + throw e; + } + req.onsuccess = function (evt) { + console.log("Insertion in DB successful"); + displayActionSuccess(); + displayPubList(store); + }; + req.onerror = function() { + console.error("addPublication error", this.error); + displayActionFailure(this.error); + }; + } + + /** + * @param {string} biblioid + */ + function deletePublicationFromBib(biblioid) { + console.log("deletePublication:", arguments); + var store = getObjectStore(DB_STORE_NAME, 'readwrite'); + var req = store.index('biblioid'); + req.get(biblioid).onsuccess = function(evt) { + if (typeof evt.target.result == 'undefined') { + displayActionFailure("No matching record found"); + return; + } + deletePublication(evt.target.result.id, store); + }; + req.onerror = function (evt) { + console.error("deletePublicationFromBib:", evt.target.errorCode); + }; + } + + /** + * @param {number} key + * @param {IDBObjectStore=} store + */ + function deletePublication(key, store) { + console.log("deletePublication:", arguments); + + if (typeof store == 'undefined') + store = getObjectStore(DB_STORE_NAME, 'readwrite'); + + // As per spec http://www.w3.org/TR/IndexedDB/#object-store-deletion-operation + // the result of the Object Store Deletion Operation algorithm is + // undefined, so it's not possible to know if some records were actually + // deleted by looking at the request result. + var req = store.get(key); + req.onsuccess = function(evt) { + var record = evt.target.result; + console.log("record:", record); + if (typeof record == 'undefined') { + displayActionFailure("No matching record found"); + return; + } + // Warning: The exact same key used for creation needs to be passed for + // the deletion. If the key was a Number for creation, then it needs to + // be a Number for deletion. + req = store.delete(key); + req.onsuccess = function(evt) { + console.log("evt:", evt); + console.log("evt.target:", evt.target); + console.log("evt.target.result:", evt.target.result); + console.log("delete successful"); + displayActionSuccess("Deletion successful"); + displayPubList(store); + }; + req.onerror = function (evt) { + console.error("deletePublication:", evt.target.errorCode); + }; + }; + req.onerror = function (evt) { + console.error("deletePublication:", evt.target.errorCode); + }; + } + + function displayActionSuccess(msg) { + msg = typeof msg != 'undefined' ? "Success: " + msg : "Success"; + $('#msg').html('<span class="action-success">' + msg + '</span>'); + } + function displayActionFailure(msg) { + msg = typeof msg != 'undefined' ? "Failure: " + msg : "Failure"; + $('#msg').html('<span class="action-failure">' + msg + '</span>'); + } + function resetActionStatus() { + console.log("resetActionStatus ..."); + $('#msg').empty(); + console.log("resetActionStatus DONE"); + } + + function addEventListeners() { + console.log("addEventListeners"); + + $('#register-form-reset').click(function(evt) { + resetActionStatus(); + }); + + $('#add-button').click(function(evt) { + console.log("add ..."); + var title = $('#pub-title').val(); + var biblioid = $('#pub-biblioid').val(); + if (!title || !biblioid) { + displayActionFailure("Required field(s) missing"); + return; + } + var year = $('#pub-year').val(); + if (year != '') { + // Better use Number.isInteger if the engine has EcmaScript 6 + if (isNaN(year)) { + displayActionFailure("Invalid year"); + return; + } + year = Number(year); + } else { + year = null; + } + + var file_input = $('#pub-file'); + var selected_file = file_input.get(0).files[0]; + console.log("selected_file:", selected_file); + // Keeping a reference on how to reset the file input in the UI once we + // have its value, but instead of doing that we rather use a "reset" type + // input in the HTML form. + //file_input.val(null); + var file_url = $('#pub-file-url').val(); + if (selected_file) { + addPublication(biblioid, title, year, selected_file); + } else if (file_url) { + addPublicationFromUrl(biblioid, title, year, file_url); + } else { + addPublication(biblioid, title, year); + } + + }); + + $('#delete-button').click(function(evt) { + console.log("delete ..."); + var biblioid = $('#pub-biblioid-to-delete').val(); + var key = $('#key-to-delete').val(); + + if (biblioid != '') { + deletePublicationFromBib(biblioid); + } else if (key != '') { + // Better use Number.isInteger if the engine has EcmaScript 6 + if (key == '' || isNaN(key)) { + displayActionFailure("Invalid key"); + return; + } + key = Number(key); + deletePublication(key); + } + }); + + $('#clear-store-button').click(function(evt) { + clearObjectStore(); + }); + + var search_button = $('#search-list-button'); + search_button.click(function(evt) { + displayPubList(); + }); + + } + + openDb(); + addEventListeners(); + +})(); // Immediately-Invoked Function Expression (IIFE) +</pre> + +<p>{{ LiveSampleLink('Full_IndexedDB_example', "Test the online live demo") }}</p> + +<h2 id="Nächster_Schritt">Nächster Schritt</h2> + +<p>If you want to start tinkering with the API, jump in to the <a href="/en/IndexedDB" title="https://developer.mozilla.org/en/IndexedDB">reference documentation</a> and checking out the different methods.</p> + +<h2 id="Siehe_auch">Siehe auch</h2> + +<p>Reference</p> + +<ul> + <li><a href="/en/IndexedDB" title="https://developer.mozilla.org/en/IndexedDB">IndexedDB API Reference</a></li> + <li><a class="external" href="http://www.w3.org/TR/IndexedDB/" title="http://www.w3.org/TR/IndexedDB/">Indexed Database API Specification</a></li> + <li><a href="/en-US/docs/IndexedDB/Using_IndexedDB_in_chrome" title="/en-US/docs/IndexedDB/Using_IndexedDB_in_chrome">Using IndexedDB in chrome</a></li> +</ul> + +<p>Tutorials</p> + +<ul> + <li><a class="external" href="http://www.html5rocks.com/tutorials/indexeddb/todo/" title="http://www.html5rocks.com/tutorials/indexeddb/todo/">A simple TODO list using HTML5 IndexedDB</a><span class="external">. {{Note("This tutorial is based on an old version of the specification and does not work on up-to-date browsers - it still uses the removed <code>setVersion()</code> method.") }}</span></li> + <li><a href="http://www.html5rocks.com/en/tutorials/indexeddb/uidatabinding/" title="http://www.html5rocks.com/en/tutorials/indexeddb/uidatabinding/">Databinding UI Elements with IndexedDB</a></li> +</ul> + +<p>Related articles</p> + +<ul> + <li><a class="external" href="http://msdn.microsoft.com/en-us/scriptjunkie/gg679063.aspx" title="http://msdn.microsoft.com/en-us/scriptjunkie/gg679063.aspx">IndexedDB — The Store in Your Browser</a></li> +</ul> + +<p>Firefox</p> + +<ul> + <li>Mozilla <a class="link-https" href="https://mxr.mozilla.org/mozilla-central/find?text=&string=dom%2FindexedDB%2F.*%5C.idl&regexp=1" title="https://mxr.mozilla.org/mozilla-central/find?text=&string=dom/indexedDB/.*\.idl&regexp=1">interface files</a></li> +</ul> |