[Bug 21559] New: [IndexedDB] Term "primary key" needs defining


            Bug ID: 21559
           Summary: [IndexedDB] Term "primary key" needs defining
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
          Assignee: dave.null@w3.org
          Reporter: jsbell@chromium.org
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

The term "primary key" is used in the spec in a couple of places:

(1)  3.2.6 Index
"getKey - Gets the primary key of the record from the referenced object store

In this case, the word "primary" can simply be dropped; it's already referring
to the referenced object store, and the algorithm clearly defines what should

(2) 3.5.7 Cursor Iteration Operation
"If /found record/ is not defined, set /cursor/'s /key/ and primary key to

This blurs the line between the IDBCursor (the IDL interface) and the abstract
cursor mechanism defined in 3.1.10. IDBCursor has |key|, |primaryKey| and (for
IDBCursorWithValue) |value| attributes. A cursor has /position/, /key/ and
/value/ properties, and defines /effective key/ (if the source is an index).

The algorithm should not refer to the IDL attributes, but the properties of the
cursor mechanism. 

Given that:

"IDBCursor.primaryKey Returns the cursor's current effective key."
"If the source of a cursor is an index, the effective object store of the
cursor is that index's referenced object store and the effective key is the
cursor's object store position."

.. then it should be sufficient to state:

"If /found record/ is not defined, set /cursor/'s /key/ to undefined. If
/source/ is an index, set /cursor/'s /object store position/ to undefined."

You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 3 April 2013 00:00:16 UTC