Backlog
3Under consideration
Syncing edit states
Background In Dynomate, there are currently two ways to edit an item: Quick Edit (context menu) Triggered from the row’s context menu. Edits are applied immediately to DynamoDB (no staging). Inline / JSON Editor (sidebar) Editing directly in the table cell or in the JSON sidebar. Edits are staged and must be explicitly confirmed as part of a 2-step process before being written to DynamoDB. Problem If a user: Makes an inline/JSON edit to an item → edit becomes staged. Then performs a Quick Edit on the same item (instead of confirming the staged change), The original staged operations remain in the “pending” state, even though the underlying item has changed. This leads to: Stale staged operations that don’t match the current item in the table. Potentially dangerous writes if the user later confirms a staged edit that was created against an out-of-date version of the item. Confusing UX: the staged badge / count suggests there are valid pending changes, but the table is showing newer data. We need the staged operations to stay in sync with the state of the table, and to be automatically refreshed or cancelled when they become stale. Desired Behavior / High-Level Requirements Staged operations sync with table refreshes/updates Whenever the table data is refreshed (manual refresh, batch operations, re-query, pagination change, filter change, or background refresh), Dynomate should: Reconcile staged operations against the latest item data. Cancel or mark as invalid any staged operations that no longer match the item’s current state. Quick Edit should reconcile staged edits If a Quick Edit is performed on an item that has existing staged edits: Either: (Preferred) Automatically cancel the staged edits for that item, or Surface a clear UX state (“Staged edits invalidated due to newer changes”) and remove them from the “to be applied” batch. The user should never be able to accidentally confirm an edit that was staged before a newer Quick Edit.
Same Table - Multiple Tabs
i’d like to have different queries across the same table. perhaps this means the same table in multiple tabs, or some other approach could be possible
Grouping for imported tables
Some developers use prefixes for tables so July-* for tables deployed via July’s stack, Orlando-* for tables deployed via Orlando’s stack. It might be helpful to allow grouping the tables imported by some table name pattern. E.g. Dev-*
Next up
Committed and queued
No Next up issues
In Progress
1Actively being built
Done
20Recently shipped
Import / Export table
Ability to import / export Dynamo table from/to s3
Apply filter to Scan operations
Analogous to core DynoBase functionality; for Scan operations: Apply filters to arbitrary attributes (not PK/SK) Sort columns (ASC/DESC per attribute) based on responses
Number comparison error in Query
When running a comparision query with a number as the sort key, the queries are unsuccessful in the table view.
Global search
Make it possible to search for tables and requests by name.
Onboarding & Intro docs
A walkthrough or tutorial for new users to get information about how Dynomate works, prerequisites and available features.
Linux - Unable to open download folder (full table exports)
Linux users are unable to open download folder after a full table exports due to a permission issue. Location is ~/.local/share/Dynomate/exports Tested on Ubuntu
Export current page option
Provide an option to export data in the current page/view while querying or scanning. Option to export as CSV or export as JSON. TBD - Button in action panel vs context menu.
Row count
Implement row count to show the number of items in the current view for Query and scan views.
Bug - Inline update errors out for arrays
When modifying items inline using the JSON editor, changes to fields of array type lead to an error.
Multi-select rows
Analogous to DynoBase: In Scan or Query results, select Table View Select multiple rows (Shift + Click, or Ctrl + Click) and perform Delete or Export operations