Rename my_tickets table to user_tickets and enforce consistent table naming for ticket ownership #19

Open
opened 2025-10-29 09:44:36 +00:00 by H3ALY · 0 comments
Owner

The current table name my_tickets is unclear and does not follow a standard database naming convention. The planned architecture separates:

Individual user tickets

Syndicate tickets

To reflect this design intent, the my_tickets table should be renamed to user_tickets, including updates across:

Schema (table name)

Storage layer

Handler queries

Migrations

Composite indexes and foreign keys

Documentation references

This aligns naming with business logic and future-proof design.

Current Behavior

InsertTicket queries my_tickets

List handler queries my_tickets and will soon be moved into storage

Foreign key and indexing still local to current design

Why This Matters

Clear separation between personal vs syndicate-owned tickets

Standardized naming improves schema clarity and maintainability

Avoids future confusion when syndicate tables are added

Scope
Create migration to rename table: my_tickets → user_tickets
Update all queries in storage/tickets/... to the new name
Update hard-coded SQL in handlers (before removal into storage layer)
Documentation update in platform reference + README
Optionally rename duplicate boolean to is_duplicate

Non-Goals

No changes to ticket schema contents

No changes to the UI flow

No assumption about syndicate tables yet (tracked separately)

Risks

Requires coordinated deploy with zero tickets inserted between rename & code update

Existing code must not reference old table name after migration

Acceptance Criteria
All SQL references updated to user_tickets
Insert and list behaviors fully preserved
Storage layer fully abstracts SQL (handlers no longer query DB)
Documentation updated accordingly
No tickets lost or duplicated during rename

Effort Estimate:
Low–Medium (1 day including testing)

Dependencies / Integration Notes

This backlog item should be done after:

The user_id enforcement backlog item

Moving SQL queries out of list.go into storage/tickets

Otherwise, renaming will multiply required fixes.

The current table name my_tickets is unclear and does not follow a standard database naming convention. The planned architecture separates: Individual user tickets Syndicate tickets To reflect this design intent, the my_tickets table should be renamed to user_tickets, including updates across: Schema (table name) Storage layer Handler queries Migrations Composite indexes and foreign keys Documentation references This aligns naming with business logic and future-proof design. Current Behavior InsertTicket queries my_tickets List handler queries my_tickets and will soon be moved into storage Foreign key and indexing still local to current design Why This Matters Clear separation between personal vs syndicate-owned tickets Standardized naming improves schema clarity and maintainability Avoids future confusion when syndicate tables are added Scope ✅ Create migration to rename table: my_tickets → user_tickets ✅ Update all queries in storage/tickets/... to the new name ✅ Update hard-coded SQL in handlers (before removal into storage layer) ✅ Documentation update in platform reference + README ✅ Optionally rename duplicate boolean to is_duplicate Non-Goals No changes to ticket schema contents No changes to the UI flow No assumption about syndicate tables yet (tracked separately) Risks Requires coordinated deploy with zero tickets inserted between rename & code update Existing code must not reference old table name after migration Acceptance Criteria ✅ All SQL references updated to user_tickets ✅ Insert and list behaviors fully preserved ✅ Storage layer fully abstracts SQL (handlers no longer query DB) ✅ Documentation updated accordingly ✅ No tickets lost or duplicated during rename Effort Estimate: Low–Medium (1 day including testing) Dependencies / Integration Notes This backlog item should be done after: The user_id enforcement backlog item Moving SQL queries out of list.go into storage/tickets Otherwise, renaming will multiply required fixes.
Sign in to join this conversation.