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

Does update-table only support provisioned throughput? #77

Closed
ricardojmendez opened this issue Dec 11, 2015 · 2 comments
Closed

Does update-table only support provisioned throughput? #77

ricardojmendez opened this issue Dec 11, 2015 · 2 comments

Comments

@ricardojmendez
Copy link
Collaborator

I'd like to confirm - does update-table only support provisioned throughput? I can provide a pull request to add other functionality as well, such as updating secondary indexes, but wanted to confirm first that it's not already supported elsewhere (I'm new to faraday).

@ptaoussanis
Copy link
Member

Hi Ricardo, that's correct - current update-table supports only throughput changes.

Would be happy to see a PR with other functionality, thank you! Please target the dev branch for any PR work.

Cheers :-)

@ricardojmendez
Copy link
Collaborator Author

Thanks. Closing the issue, as it was specific to the question. I may add some more features but will get acquainted with the dev brach first,to get familiar with the parameter conventions.

ricardojmendez added a commit that referenced this issue Dec 19, 2015
* Renamed environment sample, more useful as a script
* Global secondary index tests for create-table
* Local secondary index tests

* BREAKING CHANGE: update-table now receives options in a map [1]
This commit only changes throughput so that it's passed as an option in
a map, as discussed on #78. It's still required, which it shouldn't be
since it's not the only option to change.

* We no longer need to do stepping when updating throughput
See discussion on #78

* Elaborating on table-status-watch comment
* Tests for decreasing throughput
* Disregarding throughput updates that are the same as the current values
Found that updateTable hangs if we pass the same throughput values as
the table currently has (see #79).  Refactored throughput parameter
validation to its own function, since we'll need to validate the
parameters for the other operations as well.

* Expanded tests.
* Updating encore and AWS SDK version, all tests passing
Want to make sure we're running against the latest version, to avoid
behavior like #79 being a known (and possibly solved) issue.

* Upgraded expectations, re-wrote tests that used expect-let
* Sending empty map to update-table should have no effect
See 8574687, this test should have gone in with that commit.

* Global secondary index creation on update-table, see #80
* update-table can now change throughput on :gsindexes (#80)
Also, new function: index-status-watch

* update-table can now delete :gsindexes (#80)
* Support for specifying index on scan (#82)
* Supporting projection and expr-attr-names on scan (#82)
* Added support for conditional deletes (#84)
* Added missing tests for expressions on update-item-request
* BREAKING CHANGE: update-map is now another value on update-item's params
Updated tests, fixed deprecation warning. See #83.

* Expanded docstring for update-table (#80)
ptaoussanis added a commit that referenced this issue Dec 19, 2015
ptaoussanis added a commit that referenced this issue Dec 19, 2015
Gave the entire codebase a quick once over, cleaning up some long-accumulated
changes. Could do with a proper refactor but this'll have to do for now.
ricardojmendez added a commit that referenced this issue Dec 22, 2015
* Renamed environment sample, more useful as a script
* Global secondary index tests for create-table
* Local secondary index tests

* BREAKING CHANGE: update-table now receives options in a map [1]
This commit only changes throughput so that it's passed as an option in
a map, as discussed on #78. It's still required, which it shouldn't be
since it's not the only option to change.

* We no longer need to do stepping when updating throughput
See discussion on #78

* Elaborating on table-status-watch comment
* Tests for decreasing throughput
* Disregarding throughput updates that are the same as the current values
Found that updateTable hangs if we pass the same throughput values as
the table currently has (see #79).  Refactored throughput parameter
validation to its own function, since we'll need to validate the
parameters for the other operations as well.

* Expanded tests.
* Updating encore and AWS SDK version, all tests passing
Want to make sure we're running against the latest version, to avoid
behavior like #79 being a known (and possibly solved) issue.

* Upgraded expectations, re-wrote tests that used expect-let
* Sending empty map to update-table should have no effect
See 8574687, this test should have gone in with that commit.

* Global secondary index creation on update-table, see #80
* update-table can now change throughput on :gsindexes (#80)
Also, new function: index-status-watch

* update-table can now delete :gsindexes (#80)
* Support for specifying index on scan (#82)
* Supporting projection and expr-attr-names on scan (#82)
* Added support for conditional deletes (#84)
* Added missing tests for expressions on update-item-request
* BREAKING CHANGE: update-map is now another value on update-item's params
Updated tests, fixed deprecation warning. See #83.

* Expanded docstring for update-table (#80)
ptaoussanis added a commit that referenced this issue Dec 22, 2015
Gave the entire codebase a quick once over, cleaning up some long-accumulated
changes. Could do with a proper refactor but this'll have to do for now.
ricardojmendez added a commit that referenced this issue Dec 22, 2015
* Renamed environment sample, more useful as a script
* Global secondary index tests for create-table
* Local secondary index tests

* BREAKING CHANGE: update-table now receives options in a map [1]
This commit only changes throughput so that it's passed as an option in
a map, as discussed on #78. It's still required, which it shouldn't be
since it's not the only option to change.

* We no longer need to do stepping when updating throughput
See discussion on #78

* Elaborating on table-status-watch comment
* Tests for decreasing throughput
* Disregarding throughput updates that are the same as the current values
Found that updateTable hangs if we pass the same throughput values as
the table currently has (see #79).  Refactored throughput parameter
validation to its own function, since we'll need to validate the
parameters for the other operations as well.

* Expanded tests.
* Updating encore and AWS SDK version, all tests passing
Want to make sure we're running against the latest version, to avoid
behavior like #79 being a known (and possibly solved) issue.

* Upgraded expectations, re-wrote tests that used expect-let
* Sending empty map to update-table should have no effect
See 8574687, this test should have gone in with that commit.

* Global secondary index creation on update-table, see #80
* update-table can now change throughput on :gsindexes (#80)
Also, new function: index-status-watch

* update-table can now delete :gsindexes (#80)
* Support for specifying index on scan (#82)
* Supporting projection and expr-attr-names on scan (#82)
* Added support for conditional deletes (#84)
* Added missing tests for expressions on update-item-request
* BREAKING CHANGE: update-map is now another value on update-item's params
Updated tests, fixed deprecation warning. See #83.

* Expanded docstring for update-table (#80)
ptaoussanis added a commit that referenced this issue Dec 22, 2015
Gave the entire codebase a quick once over, cleaning up some long-accumulated
changes. Could do with a proper refactor but this'll have to do for now.
ptaoussanis pushed a commit that referenced this issue Jan 23, 2016
* Renamed environment sample, more useful as a script
* Global secondary index tests for create-table
* Local secondary index tests

* BREAKING CHANGE: update-table now receives options in a map [1]
This commit only changes throughput so that it's passed as an option in
a map, as discussed on #78. It's still required, which it shouldn't be
since it's not the only option to change.

* We no longer need to do stepping when updating throughput
See discussion on #78

* Elaborating on table-status-watch comment
* Tests for decreasing throughput
* Disregarding throughput updates that are the same as the current values
Found that updateTable hangs if we pass the same throughput values as
the table currently has (see #79).  Refactored throughput parameter
validation to its own function, since we'll need to validate the
parameters for the other operations as well.

* Expanded tests.
* Updating encore and AWS SDK version, all tests passing
Want to make sure we're running against the latest version, to avoid
behavior like #79 being a known (and possibly solved) issue.

* Upgraded expectations, re-wrote tests that used expect-let
* Sending empty map to update-table should have no effect
See 8574687, this test should have gone in with that commit.

* Global secondary index creation on update-table, see #80
* update-table can now change throughput on :gsindexes (#80)
Also, new function: index-status-watch

* update-table can now delete :gsindexes (#80)
* Support for specifying index on scan (#82)
* Supporting projection and expr-attr-names on scan (#82)
* Added support for conditional deletes (#84)
* Added missing tests for expressions on update-item-request
* BREAKING CHANGE: update-map is now another value on update-item's params
Updated tests, fixed deprecation warning. See #83.

* Expanded docstring for update-table (#80)
ptaoussanis added a commit that referenced this issue Jan 23, 2016
Gave the entire codebase a quick once over, cleaning up some long-accumulated
changes. Could do with a proper refactor but this'll have to do for now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants