schema specification shouldn't rely on object key order about dynamo

[jed]

this library is node-only, which means all we need to do is confirm to v8's handling, which iterates in insertion order EXCEPT when numbers are used as keys. that's really the only case where i could see this fail, and it is pretty rare. providing a dead-easy API with a fallback to the original raw API for when this isn't good enough is a pretty good compromise, i think, but am willing to entertain pull requests that add the ability to use arrays without affecting the current API.

I asked about this on StackOverflow, and opinion seems to be against doing this for node libraries. I think the problem arises when (for performance reasons), V8 decides to change its implementation. Libraries which build against the current API will break.

Another problem is that relying on an undocumented behavior in an API specification may cause confusion for some programmers. Ordered keys in hashtables are an unusual behavior, and a reader of dynamo.js schemas who isn't familiar with these semantics may not get what is happening.

(What file is this code in, btw? Maybe I'll take a crack at it.)

[jed]

wow, some opinionated people in that thread.

i'd like to add support for more explicit key order, but there are several options:

• accepting an array
• accepting a hash with hash and range keys that have Object values
• requiring a schema to be specified when a table is created

i think the first is the most straightforward.

there are two places that would need attention: Key.js and KeySchema.js. i'm in favor or allowing arrays using isArray to check. would you like to take a crack at it?

Excellent. I will try to take a look, but can't promise anything quickly. (Or if someone can get to it before me, please do)

[mlogan]

Hi everyone,

I took a crack at this: See #35

Comments welcome.

Thanks,
Mark

[jed]

fixed by @mlogan in #35.