Query support

[jeremydaly]

Someone mentioned this to me, but I’m not sure of the correct abstraction level. If the models and types can aid in building queries, then I think this would be useful, but I don’t want to cross into ORM territory.

There are a limited set of sortKey operations, so some simple abstraction could work, but the library probably shouldn’t be parsing queries. There would likely need to be a different way to input it, and I don’t think chaining makes sense in this case (e.g. .field(‘somevalue‘).gt().value(someValue)).

This needs more feedback.

[tomaswisten]

Yes, querying seems to be the missing piece for my use cases as well. Thanks for a promising project!

[sreimer15]

So I've been playing around with nosql-workbench from aws and they have a concept of a "facet".

Which is the "The access patterns of the application that will interact with the table."
In that GUI
You can define a name for your facet
an alias for the partion key
and an alias for your sort key
as well as "other attributes" to include

So perhaps in your domain object you can define a "facet" with its own primary and secondary key compositions as well as aliases. That way you're encouraging the end user to think about their access patterns before hand.

const item = { 
   globalSortKeyAlias,
   primaryKeyAlias
}

User.query("facetName", item)

Perhaps other attribute projection is not part of the MVP

What do you think? I really like what you've done and I appreciate the care you've put in to encourage best practices and single table design with dynamo db. Thank you!

[jeremydaly]

Thanks for the feedback and kind words @sreimer15! The access pattern/facet thing was something I was thinking about in issue #8, but that's an interesting thought to tie the two together.

I think there still needs to be a low-level querying capability, but definitely something to think of.

[DaKaZ]

@jeremydaly what do you think about this syntax for building the query params:

Model.query({
  pk: 'hashKey', // you would use your Model's pk definition or alias here
  index: 'gsiName', // optional, only if using a GSI with query
  limit: 10, // optional limit
  sortKey: {  // optional, if omitted the query would just be on the partition key
    operator: '=', // =, >, >=, <, <=, between, begins_with
    value: '',
    secondaryValue: '', // only used with between
    consistentRead: true, // optional, default false
  },
  filter: { // filter is optional
    key: 'keyName',
    operator: '=', // =, >, >=, <, <=, between, begins_with
    value: '',
    secondaryValue: '' // only used with between
  }
})

It seems like we could build all the syntax needed with that and it would similar syntax/methods as the get/put functionality in the library already. So a minimal example would look like:

const queryParams = MyModel.query({ pk: '123abc' })

And a more complete example:

const queryParams = MyModel.query({ 
  pk: '123abc',
  limit: 10,
  sortKey: {
    operator: 'begins_with'
    value: 'meta' // the first part of a compounded key
  }
})

[jeremydaly]

Added in the v0.2 branch.