Skip to content
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

Open
kretz opened this issue Oct 20, 2014 · 7 comments
Open

Feature request: support global secondary indexes #34

kretz opened this issue Oct 20, 2014 · 7 comments

Comments

@kretz
Copy link

kretz commented Oct 20, 2014

DynamoDB has new cool features that this library would be even better with: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html

@victorquinn
Copy link
Owner

👍

Didn't know that existed, will have to pull that in!

@adambom
Copy link

adambom commented Dec 22, 2014

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).

@williamcoates
Copy link
Contributor

This seems to have been added in a917bb8. I haven't actually used it though...

@victorquinn
Copy link
Owner

victorquinn commented Apr 28, 2016

Just to comment on one thing here from the post above (that's admittedly very old heh):

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 idk).

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 insert and remove whereas AWS has putItem and deleteItem.

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).

@tri-hoang
Copy link

Hi, I am wondering were you able to test this feature yet?
If yes, can you give me an example?
Thank you!

@jasonfutch
Copy link

Is there an example of how to find() with a secondary index?

@mariopeixoto
Copy link
Contributor

Any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants