-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: support global secondary indexes #34
Comments
👍 Didn't know that existed, will have to pull that in! |
Currently dynasty lacks support for two params to the createTable function (documented here: http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/DynamoDB.html#createTable-property). The missing params are LocalSecondaryIndexes, and GlobalSecondaryIndexes. For querying over any significant volume of data, indexes are critical, and these options should be added to dynasty. As a first pass, we could just pass through whatever params the end user passes in, e.g. dynasty.create('lands', {
key_schema: {
hash: ['name', 'string']
},
localSecondaryIndexes: [
{
IndexName: 'index_name',
KeySchema: [...]
..
}, ...
]
} The only question is what to do about the capitalization/case convention, which seems to be pretty inconsistent across the board (mix of camel and snake in dynasty, title case in aws sdk). |
This seems to have been added in a917bb8. I haven't actually used it though... |
Just to comment on one thing here from the post above (that's admittedly very old heh):
Agreed and this is something I've been meaning to clean up. My initial intent with Dynasty was to make Dynamo more palatable because I found the AWS SDK to be unreasonably clunky with its naming conventions and API. Hence why Dynasty has methods like Not only are the names simplified (and closer to what most devs are probably used to coming from Mongo or other document storage dbs), but the arguments necessary to make things happen are as well and Dynasty tries to have helpful defaults for many things. Compare the following AWS syntax: dynamoDB.createTable({
AttributeDefinitions: [
{ AttributeName: 'name', AttributeType: 'S' },
{ AttributeName: 'email', AttributeType: 'S' },
{ AttributeName: 'data', AttributeType: 'M' },
{ AttributeName: 'active', AttributeType: 'BOOL' }
],
KeySchema: [
{ AttributeName: 'email' },
{ KeyType: 'HASH' }
],
ProvisionedThroughput: {
ReadCapacityUnits: 10,
WriteCapacityUnits: 5
},
TableName: 'users',
}, function(err, data) {
if (err) {
console.log(err, err.stack);
} else {
console.log(data);
}
})` to the equivalent Dynasty dynasty.create('users', { key_schema: { hash: [ 'email', 'string' ] } })
.then(console.log)
.catch(function(err) {
console.log(err, err.stack);
}); Relatedly, Dynasty also tries to do more automatically for you, such as updating the table to add columns for you automatically when you insert an item with those columns, and takes care of the mapping between JavaScript types and the AWS equivalents. Anyway, as much as is possible or reasonable without breaking things, I'd like to make sure Dynasty keeps the cleaner API and isn't inconsistent with the camel and snake case. Generally, the camel case stuff is Dynamo getting through Dynasty's layer of abstraction unaltered and that is almost entirely unintentional. I know that's neither here nor there but wanted to comment on it. I think @williamcoates is correct that this is already implemented, but I'll leave this ticket open until I can verify (and hopefully write some tests for it). |
Hi, I am wondering were you able to test this feature yet? |
Is there an example of how to find() with a secondary index? |
Any updates on this? |
DynamoDB has new cool features that this library would be even better with: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html
The text was updated successfully, but these errors were encountered: