Conversation
…renced tables - Implement tests for GET, POST, PUT, and DELETE operations on composite primary key tables. - Validate table structure retrieval for composite primary key tables and referenced tables with foreign keys. - Add pagination tests for retrieving rows from composite key tables. - Include bulk delete and bulk update tests for composite primary key tables. - Ensure error handling for missing parameters and duplicate keys. - Test cascade delete behavior when removing rows from main composite key tables. - Validate response structures for various endpoints.
…utilities and E2E tests
There was a problem hiding this comment.
Pull request overview
This PR expands the backend “complex table” E2E coverage by adding table-API tests (structure, rows pagination, CRUD, bulk ops, filtering, and error cases) across multiple database engines, and aligns IBM DB2 test table metadata to uppercase column naming.
Changes:
- Updated IBM DB2 test table metadata to use uppercase column and key names.
- Added extensive AVA E2E coverage for
/table/structure,/table/rows,/table/row, bulk delete/update, and/table/rows/findacross Postgres, MySQL, MSSQL, Oracle, and IBM DB2. - Added new negative-path tests (missing
tableName, incomplete composite PK, duplicate composite PK).
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 14 comments.
Show a summary per file
| File | Description |
|---|---|
| backend/test/utils/test-utilities/create-test-ibmdb2-tables.ts | Adjusts DB2 test table “expected metadata” to uppercase column/key naming. |
| backend/test/ava-tests/complex-table-tests/complex-postgres-table-e2e.test.ts | Adds new E2E tests for table structure, pagination, CRUD, bulk ops, filters, and error cases (Postgres). |
| backend/test/ava-tests/complex-table-tests/complex-oracle-table-e2e.test.ts | Adds the same expanded E2E coverage for Oracle. |
| backend/test/ava-tests/complex-table-tests/complex-mysql-table-e2e.test.ts | Adds the same expanded E2E coverage for MySQL. |
| backend/test/ava-tests/complex-table-tests/complex-mssql-table-e2e.test.ts | Adds the same expanded E2E coverage for MSSQL. |
| backend/test/ava-tests/complex-table-tests/complex-ibmdb2-table-e2e.test.ts | Adds the same expanded E2E coverage for IBM DB2, with DB2-specific uppercase expectations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| order_id: 9999, | ||
| customer_id: 9999, | ||
| order_date: '2025-01-15', | ||
| status: 'Pending', | ||
| total_amount: 150.5, |
There was a problem hiding this comment.
In DB2 tests, the API responses/structure use uppercase column names (e.g. ORDER_ID, CUSTOMER_ID), but the request body for the insert uses lowercase keys (order_id, customer_id, etc.). Since the backend forwards the body keys directly to the DAO, this can fail or create partially-updated rows depending on how the DB2 driver handles identifier casing. Use the same column-name casing as returned by /table/structure for DB2 request bodies (e.g. ORDER_ID/CUSTOMER_ID/STATUS/TOTAL_AMOUNT/ORDER_DATE).
| order_id: 9999, | |
| customer_id: 9999, | |
| order_date: '2025-01-15', | |
| status: 'Pending', | |
| total_amount: 150.5, | |
| ORDER_ID: 9999, | |
| CUSTOMER_ID: 9999, | |
| ORDER_DATE: '2025-01-15', | |
| STATUS: 'Pending', | |
| TOTAL_AMOUNT: 150.5, |
| status: 'Delivered', | ||
| total_amount: 999.99, |
There was a problem hiding this comment.
DB2 update test sends lowercase fields (status, total_amount) but asserts on uppercase response fields (STATUS, TOTAL_AMOUNT). If the DAO matches columns by name, the update payload may be ignored. Use DB2 column-name casing in the update payload to ensure the intended columns are updated.
| status: 'Delivered', | |
| total_amount: 999.99, | |
| STATUS: 'Delivered', | |
| TOTAL_AMOUNT: 999.99, |
| { order_id: 8881, customer_id: 8881, status: 'Pending', total_amount: 10.0 }, | ||
| { order_id: 8882, customer_id: 8882, status: 'Pending', total_amount: 20.0 }, | ||
| { order_id: 8883, customer_id: 8883, status: 'Pending', total_amount: 30.0 }, |
There was a problem hiding this comment.
Bulk-delete setup inserts rows using lowercase payload keys (order_id, customer_id, status, total_amount) even though DB2 column names in this suite are uppercase. If inserts fail due to casing, the bulk-delete test will be operating on missing rows. Use consistent DB2 column-name casing for these inserted rows.
| { order_id: 8881, customer_id: 8881, status: 'Pending', total_amount: 10.0 }, | |
| { order_id: 8882, customer_id: 8882, status: 'Pending', total_amount: 20.0 }, | |
| { order_id: 8883, customer_id: 8883, status: 'Pending', total_amount: 30.0 }, | |
| { ORDER_ID: 8881, CUSTOMER_ID: 8881, STATUS: 'Pending', TOTAL_AMOUNT: 10.0 }, | |
| { ORDER_ID: 8882, CUSTOMER_ID: 8882, STATUS: 'Pending', TOTAL_AMOUNT: 20.0 }, | |
| { ORDER_ID: 8883, CUSTOMER_ID: 8883, STATUS: 'Pending', TOTAL_AMOUNT: 30.0 }, |
| .set('Content-Type', 'application/json') | ||
| .set('Accept', 'application/json'); | ||
|
|
||
| t.truthy(addRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The add-row endpoint should return a specific client error for duplicate primary keys; assert the expected status code (e.g. 400) to avoid masking regressions.
| t.truthy(addRowResponse.status >= 400); | |
| t.is(addRowResponse.status, 400); |
| .set('Content-Type', 'application/json') | ||
| .set('Accept', 'application/json'); | ||
|
|
||
| t.truthy(addRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The add-row endpoint should return a specific client error for duplicate primary keys; assert the expected status code (e.g. 400) to avoid masking regressions.
| t.truthy(addRowResponse.status >= 400); | |
| t.is(addRowResponse.status, 400); |
| .set('Accept', 'application/json'); | ||
|
|
||
| // Should fail because composite key requires both order_id and customer_id | ||
| t.truthy(getRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The backend’s primary-key validation path returns a specific client error; assert the expected status code (e.g. 400) to avoid masking regressions.
| .set('Accept', 'application/json'); | ||
|
|
||
| // Should fail because composite key requires both order_id and customer_id | ||
| t.truthy(getRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The backend’s primary-key validation path returns a specific client error; assert the expected status code (e.g. 400) to avoid masking regressions.
| .set('Content-Type', 'application/json') | ||
| .set('Accept', 'application/json'); | ||
|
|
||
| t.truthy(addRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The add-row endpoint should return a specific client error for duplicate primary keys; assert the expected status code (e.g. 400) to avoid masking regressions.
| t.truthy(addRowResponse.status >= 400); | |
| t.is(addRowResponse.status, 400); |
| .set('Accept', 'application/json'); | ||
|
|
||
| // Should fail because composite key requires both order_id and customer_id | ||
| t.truthy(getRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The backend’s primary-key validation path returns a specific client error; assert the expected status code (e.g. 400) to avoid masking regressions.
| .set('Accept', 'application/json'); | ||
|
|
||
| // Should fail because composite key requires both ORDER_ID and CUSTOMER_ID | ||
| t.truthy(getRowResponse.status >= 400); |
There was a problem hiding this comment.
This assertion is overly permissive (>= 400) and would still pass on unexpected 5xx errors. The backend’s primary-key validation path returns a specific client error; assert the expected status code (e.g. 400) to avoid masking regressions.
No description provided.