Added support of IndexedDB's 'keyPath' to that adapter by passing it...

[MarkMYoung]

...along to 'createObjectStore' and added support of it to the SQLite adapter by allowing the user to change what property(ies) is considered the primary key(s). Many lines of code are required to handle dynamic keys (perhaps they should be refactored, condensed, or something else). One positive side-effect is that key values can now be any type, not just strings.

[MarkMYoung]

I could've named the added functions differently, but I wanted all of them to start with "key".

• keyPath: Optional string parameter passed to the constructor. It's used by all of Lawnchair, but specifically IndexedDB's createObjectStore.
• keyEmbellish: Function which may adds the key, formerly hard-coded as 'key', to the object using uuid() if, and only if, the key specified by the 'keyPath' option is a simple (top level, single identifier) key, e.g. the default 'key'.
• keyExtraction: Function which uses 'keyPath' to determine what an object's key value is.
  • One topic of discussion is, should it return a scalar for simple/non-sequence key paths and an array for compound/sequence key paths as the IDB spec. says, or should be stick to better programming practices and make it always return an array?
• keyIsValid: It is possible that once an object's key value is extracted that its value is invalid--this function will answer that question.
• keyObjectComparator: A comparator functor like those used by sort. Provided a key path or let it default to the instance's key path and it will return a comparator function that can compare whether two objects are semantically equal.
• keyValueComparator: A comparator functor, analogous to and used by keyObjectComparator, which compares key values. This is not straightforward because the IDB spec. specifies how to sort/compare between different types.

So, @brianleroux,

• Does it work?
  • For IndexedDB?
  • When not specifying a key path?
  • When specifying a key path?
    • When specifying a simple identifier (e.g. 'ID')?
    • When specifying a compound identifier (e.g. 'BirthDate,LastName')?
    • When specifying a deep identifier ('Name.ID')?
    • When specifying a compound and a deep identifier?
  • For SQLite/WebSQL?
  • When not specifying a key path?
  • When specifying a key path?
    • When specifying a simple identifier?
    • When specifying a compound identifier?
    • When specifying a deep identifier?
    • When specifying a compound and a deep identifier?
• Should it be factored out of Lawnchair.js?

[brianleroux]

one nit, I do not like seeing braces start on newlines. this isn't c#. ;)

otherwise: the code looks solid. I'm also a little dismayed about how much code there is. think it should be a plugin or just part of the indexeddb adaptor.

On Thu, Feb 26, 2015 at 9:08 AM, Mark M. Young notifications@github.com wrote:

I could've named the added functions differently, but I wanted all of them to start with "key".

• keyPath: Optional string parameter passed to the constructor. It's used by all of Lawnchair, but specifically IndexedDB's createObjectStore.
• keyEmbellish: Function which may adds the key, formerly hard-coded as 'key', to the object using uuid() if, and only if, the key specified by the 'keyPath' option is a simple (top level, single identifier) key, e.g. the default 'key'.
• keyExtraction: Function which uses 'keyPath' to determine what an object's key value is.
  • One topic of discussion is, should it return a scalar for simple/non-sequence key paths and an array for compound/sequence key paths as the IDB spec. says, or should be stick to better programming practices and make it always return an array?
  • keyIsValid: It is possible that once an object's key value is extracted that its value is invalid--this function will answer that question.
• keyObjectComparator: A comparator functor like those used by sort. Provided a key path or let it default to the instance's key path and it will return a comparator function that can compare whether two objects are semantically equal.
• keyValueComparator: A comparator functor, analogous to and used by keyObjectComparator, which compares key values. This is not straightforward because the IDB spec. specifies how to sort/compare between different types.

So, @brianleroux https://github.com/brianleroux,

• Does it work?
  • For IndexedDB?
  • When not specifying a key path?
  • When specifying a key path?
    • When specifying a simple identifier (e.g. 'ID')?
    • When specifying a compound identifier (e.g. 'BirthDate,LastName')?
    • When specifying a deep identifier ('Name.ID')?
    • When specifying a compound and a deep identifier?
    • For SQLite/WebSQL?
  • When not specifying a key path?
  • When specifying a key path?
    • When specifying a simple identifier?
    • When specifying a compound identifier?
    • When specifying a deep identifier?
    • When specifying a compound and a deep identifier?
    • Should it be factored out of Lawnchair.js?

— Reply to this email directly or view it on GitHub https://github.com/brianleroux/lawnchair/pull/212#issuecomment-76219572.

[MarkMYoung]

I know you put your braces at the end with a space, but I was focusing make it solid. I've been putting my braces vertically aligned since about '98 because I found it easier to manipulate code with vi/pico. I was gonna change the formatting (or let you do it) once it was tested and approved.

Yeah, the code to process a keyPath is a bit much. If we know it works, I can make it more terse. Even if we make it a plugin (which replaces the parsing functions), the adapters will have to use the stub parsing functions as hooks. Do you have another methodology in mind?