-
Notifications
You must be signed in to change notification settings - Fork 84
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
Implementation discussion: update-table changes #78
Comments
Hi Ricardo, The breaking change you have in mind sounds good to me, thanks for checking. |
It looks like Is there a reason for this? I'm going through the referenced page but don't see a reason why the update request would be executed in steps, only the explanation for the decrease limit in a 24 hour period. |
Was the case previously that large throughput increases needed manual steps. Not sure if that's still the case or not. If not, that code's vestigial and can be removed. |
Perfect. I'll see about removing it and running some tests against an actual live instance, since I've read some remarks that the local instance disregards throughput settings (it referred to global secondary indexes, but I expect is a general characteristic). |
Ahh yes, limits like that would only apply to a live cloud instance. Not sure if this particular limit still exists though. |
No problem, I'll test. If the limits no longer exist then things would be much simpler, since I can just unify all the table updates - otherwise it'd be best to keep separate |
Testing against a live cloud instance, I can get the update to throughput to apply in a single step. Will prune that old code. |
Just confirming: that's for a large increase, yes? I.e. more than 2x or 4x the previous value? |
Correct, tried it going from {:read 1 :write 1} to {:read 16 :write 16} without stepping. No error and update returned the expected values ; First increase
{:lsindexes nil,
:gsindexes nil,
:name :temp_table_1450109809826,
:throughput
{:read 16,
:write 16,
:last-decrease nil,
:last-increase #inst "2015-12-14T16:16:58.340-00:00",
:num-decreases-today 0},
:prim-keys {:artist {:key-type :hash, :data-type :s}},
:size 0,
:status :active,
:item-count 0,
:creation-date #inst "2015-12-14T16:16:49.943-00:00",
:indexes nil}
; Second increase
{:lsindexes nil,
:gsindexes nil,
:name :temp_table_1450109809826,
:throughput
{:read 256,
:write 256,
:last-decrease nil,
:last-increase #inst "2015-12-14T16:17:03.542-00:00",
:num-decreases-today 0},
:prim-keys {:artist {:key-type :hash, :data-type :s}},
:size 0,
:status :active,
:item-count 0,
:creation-date #inst "2015-12-14T16:16:49.943-00:00",
:indexes nil} |
Great, happy to see that they've removed that limit- thanks for picking up on this. |
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.
Closing along with #80 |
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.
* 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)
* 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)
* 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)
* 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)
I'm looking into expanding update-table to add other functionality, like GlobalSecondaryIndexUpdates, since as discussed on #77, it only currently supports provisioned throughput for the table.
I see the following issues:
I'm inclined to change that third parameter to
update-table
to just be a map with the settings for the operations to apply. This would be consistent with how the table description is passed tocreate-table
and would solve both problems above, but since that'd be a breaking change I'd rather bring it up first.Thoughts?
The text was updated successfully, but these errors were encountered: