DEV Community

Sidharth Bangera
Sidharth Bangera

Posted on

Running, Saving, and Reopening a Parameterized DynamoDB PartiQL SELECT in Tables

#aws #dynamodb #database #tutorial

Introduction

When I reuse a database query, I want the query structure to stay consistent while the input value can change.

In this walkthrough, I use Tables by ServerlessCreed, a DynamoDB GUI with a PartiQL Workbench, to run a parameterized DynamoDB PartiQL SELECT, verify the returned items, save the statement, restart the application, reopen the saved query, and verify the result again.

I also include a simple syntax-error recovery check. The test uses a deterministic fixture, so I know the expected result before execution and can verify the workflow against actual data rather than relying only on a success message.

Prerequisites

To reproduce the workflow, you need:

  1. Tables by ServerlessCreed installed. The installer is available from the official download page.
  2. Access to a non-production DynamoDB environment.
  3. A table with predictable test data.
  4. A known expected result that you can compare with the query output.

For this test, I used a table named table_bulk with 120 deterministic items. The fixture was prepared so that 30 items had:

Status = BULK_EDITED
Enter fullscreen mode Exit fullscreen mode

In this table, OrderId is the partition key and Status is the sort key. Because BULK_EDITED appears on multiple items, Status was a useful field for testing a parameterized query that returned more than one record.

1. The query I wanted to reuse

Instead of putting the filter value directly into the SQL, I used a named parameter:

SELECT *
FROM "table_bulk"
WHERE "Status" = {{statusValue}};
Enter fullscreen mode Exit fullscreen mode

The parameter value for this run was:

statusValue = BULK_EDITED
Enter fullscreen mode Exit fullscreen mode

This keeps the query structure reusable while letting the value be supplied separately when the statement is run.

I opened the PartiQL Workbench, selected table_bulk, and entered the statement. Autocomplete suggestions were available again in the v3.3.37 build while I was typing.

Tables PartiQL Workbench showing table_bulk selected and the Status attribute suggested by autocomplete
After selecting table_bulk, Tables shows the Status attribute in autocomplete while I build the PartiQL SELECT.

2. Supplying the parameter and reviewing the query

When I ran the parameterized statement, Tables opened a Query parameters dialog and detected statusValue.

I entered:

BULK_EDITED
Enter fullscreen mode Exit fullscreen mode

and chose Load for review.

Tables then resolved the parameterized statement to:

SELECT *
FROM "table_bulk"
WHERE "Status" = 'BULK_EDITED';
Enter fullscreen mode Exit fullscreen mode

This review step was useful because I could see the exact statement that would be executed before running it.

Tables PartiQL Workbench showing the parameterized SELECT before entering the query parameter.

Tables Query parameters dialog prompting for the statusValue input before loading the query for review.

Tables Query parameters dialog showing statusValue with the value BULK_EDITED.
After running the parameterized statement, Tables prompts for statusValue; I entered BULK_EDITED and loaded the resolved query for review.

3. Verifying the first result

I then ran the resolved query.

The expected result was 30 matching items because the fixture had been prepared with exactly 30 items whose Status value was BULK_EDITED.

Tables returned 30 items, which matched that expectation.

This was the important verification point for the first run. I was not relying only on a generic success message; I had a known fixture and an expected result before execution.

Tables PartiQL results showing a successful query with 30 returned BULK_EDITED items.
After running the resolved SELECT, Tables returns the expected 30 items from the deterministic fixture.

4. Saving the statement and reopening it after restart

Next, I saved the parameterized template rather than only the resolved literal query.

The saved statement retained:

SELECT *
FROM "table_bulk"
WHERE "Status" = {{statusValue}};
Enter fullscreen mode Exit fullscreen mode

I then restarted Tables, returned to the PartiQL Workbench, and selected the saved statement from My statements.

The parameterized query itself was still there after restart, but the previous parameter value was not retained. Selecting the saved query opened the Query parameters dialog again, so I entered BULK_EDITED a second time.

That behavior is important: Tables preserved the reusable query template, while the input value had to be supplied again when reopening it.

After loading the value for review and rerunning the query, Tables again returned the expected 30 items.

Check First run Reopened run Expected keys/items Actual keys/items Difference
Query template {{statusValue}} present {{statusValue}} present Same saved statement Same saved statement reopened None
Parameter value Entered BULK_EDITED Re-entered BULK_EDITED Same input value Same input value None
Result 30 items 30 items 30 deterministic fixture items matching Status = BULK_EDITED Same 30-item result set observed after restart None observed

I did not export a separate key manifest for this run, so the comparison was based on the deterministic fixture and the matching 30-item result before and after restart.

Tables PartiQL Workbench showing the saved parameterized statement reopened with a Query parameters dialog for statusValue.
After restarting Tables and reopening the saved statement, the parameterized query remains intact and Tables prompts me to enter statusValue again.

5. Recovering from a syntax error

I also tested a simple recovery case by deliberately changing the statement to invalid syntax:

SELECCC *
FROM "table_bulk"
WHERE "Status" = 'BULK_EDITED';
Enter fullscreen mode Exit fullscreen mode

Tables rejected the statement and displayed:

Statement wasn't well formed, can't be processed: Expected data manipulation
Enter fullscreen mode Exit fullscreen mode

The malformed statement remained visible in the editor, so I could correct it directly instead of recreating it from scratch.

Tables PartiQL Workbench showing a malformed SELECCC statement and the resulting syntax error.
After running the deliberately malformed SELECCC statement, Tables reports a syntax error while leaving the statement in the editor for correction.

I corrected the query and ran it again. Tables reported a successful execution and returned 30 items, matching the expected fixture result.

The query history also kept the failed statement and the successful corrected statement as separate entries during this retest.

Tables PartiQL Workbench showing the corrected SELECT and a successful 30-row result after syntax-error recovery.
After correcting the statement, Tables executes the SELECT successfully and returns the expected 30 matching items.

Conclusion

This test confirmed the full workflow I wanted to verify in Tables: creating a parameterized DynamoDB PartiQL query, supplying the parameter value, checking the returned items, saving the query template, reopening it after restart, and running it again with the same expected result.

The saved statement retained the {{statusValue}} placeholder, while the parameter value had to be entered again after reopening. With the same BULK_EDITED input and unchanged fixture, both runs returned the expected 30 items.

The syntax-error check also showed that a malformed statement remained available for correction, and the corrected query returned the expected result afterward.

For this test, the most useful part of the workflow was keeping the query reusable without hard-coding the input value into the saved template, while still verifying the result against a deterministic fixture.

Top comments (0)