fix: align CustomCommandCreator.discord_id model with BIGINT column (#78) #88

Claude · 2026-03-27T06:03:59Z

Claude commented

2026-03-27 06:03:59 +00:00

Closes #78

Summary

Changed CustomCommandCreator.discord_id from CharField(max_length=20, unique=True) to BigIntegerField(unique=True) in app/db_engine.py to match the BIGINT UNIQUE NOT NULL column created by migrations/add_custom_commands_tables.sql
Removed the str(discord_id) workaround in get_creator_by_discord_id() (custom_commands.py:178) that was compensating for the type mismatch — the ORM can now compare integers directly

Files Changed

app/db_engine.py — model field type corrected
app/routers_v3/custom_commands.py — str() cast removed from ORM query

Test Results

No test suite in this repo. Changes verified by reading the modified files and confirming the diff is minimal and correct.

Other Observations

CustomCommandCreatorModel (Pydantic, custom_commands.py:26) already declares discord_id: int, so no API contract change.
help_commands.py:29 declares created_by_discord_id: str with a comment "Text to safely store Discord snowflake IDs" — that router uses raw SQL, not the Peewee ORM, and references a separate help_commands table. Out of scope for this fix.

Closes #78 ## Summary - Changed `CustomCommandCreator.discord_id` from `CharField(max_length=20, unique=True)` to `BigIntegerField(unique=True)` in `app/db_engine.py` to match the `BIGINT UNIQUE NOT NULL` column created by `migrations/add_custom_commands_tables.sql` - Removed the `str(discord_id)` workaround in `get_creator_by_discord_id()` (`custom_commands.py:178`) that was compensating for the type mismatch — the ORM can now compare integers directly ## Files Changed - `app/db_engine.py` — model field type corrected - `app/routers_v3/custom_commands.py` — `str()` cast removed from ORM query ## Test Results No test suite in this repo. Changes verified by reading the modified files and confirming the diff is minimal and correct. ## Other Observations - `CustomCommandCreatorModel` (Pydantic, `custom_commands.py:26`) already declares `discord_id: int`, so no API contract change. - `help_commands.py:29` declares `created_by_discord_id: str` with a comment "Text to safely store Discord snowflake IDs" — that router uses raw SQL, not the Peewee ORM, and references a separate `help_commands` table. Out of scope for this fix.

Claude added 1 commit 2026-03-27 06:04:00 +00:00

fix: align CustomCommandCreator.discord_id model with BIGINT column (#78 )

Build Docker Image / build (pull_request) Successful in 2m42s

Details

a85c2e5468

Closes #78

Change CharField(max_length=20) to BigIntegerField to match the BIGINT
column created by the migration. Remove the str() workaround in
get_creator_by_discord_id() that was compensating for the type mismatch.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Claude referenced this pull request

2026-03-27 06:04:10 +00:00

Fix discord_id type mismatch between model (CharField) and migration (BIGINT) #78

Claude added the

ai-reviewing

label 2026-03-27 06:15:53 +00:00

Claude reviewed 2026-03-27 06:17:13 +00:00

Claude left a comment

Review: APPROVED

Minimal, correct fix. Two-line change that removes a type mismatch between the Peewee ORM and the actual PostgreSQL schema.

Verification

Migration confirms the schema: migrations/add_custom_commands_tables.sql line 8 — discord_id BIGINT UNIQUE NOT NULL. The old CharField(max_length=20) was wrong from the start.

BigIntegerField availability: db_engine.py uses from peewee import * — BigIntegerField is a standard Peewee field type, available in scope.

str() cast removal: With CharField, Peewee passed strings to PostgreSQL which implicitly coerced them. With BigIntegerField, Peewee now generates a proper integer parameter — correct and type-safe.

Full discord_id surface area checked:

CustomCommandCreatorModel.discord_id: int (Pydantic, line 26) — already int, no API contract change
create_creator_endpoint (line 702) — calls get_creator_by_discord_id(creator.discord_id) where creator.discord_id is int from Pydantic model — correct
create_creator(creator_data) (line 711) — creator.model_dump() includes discord_id as int — correct
get_creators endpoint (line 633-635) — uses raw SQL discord_id = %s with int param — was already type-safe, unaffected
All other creator_discord_id usages — raw SQL column reads, unaffected by ORM field type

Discord snowflake range: PostgreSQL BIGINT holds up to ~9.2×10^18. Current Discord snowflakes are ~1.3×10^18 — well within range, no overflow risk.

Pre-existing (not blocking)

custom_commands.py:697 — Bad Token: {token} still exposes bearer token in logs — tracked by the PR #85 pattern, but create_creator_endpoint was not in scope for that fix
db_engine.py:21 — hardcoded fallback password still present — tracked by PR #84 (approved but not yet reflected in this branch)

## Review: APPROVED Minimal, correct fix. Two-line change that removes a type mismatch between the Peewee ORM and the actual PostgreSQL schema. ### Verification **Migration confirms the schema**: `migrations/add_custom_commands_tables.sql` line 8 — `discord_id BIGINT UNIQUE NOT NULL`. The old `CharField(max_length=20)` was wrong from the start. **`BigIntegerField` availability**: `db_engine.py` uses `from peewee import *` — `BigIntegerField` is a standard Peewee field type, available in scope. **`str()` cast removal**: With `CharField`, Peewee passed strings to PostgreSQL which implicitly coerced them. With `BigIntegerField`, Peewee now generates a proper integer parameter — correct and type-safe. **Full discord_id surface area checked**: - `CustomCommandCreatorModel.discord_id: int` (Pydantic, line 26) — already `int`, no API contract change - `create_creator_endpoint` (line 702) — calls `get_creator_by_discord_id(creator.discord_id)` where `creator.discord_id` is `int` from Pydantic model — correct - `create_creator(creator_data)` (line 711) — `creator.model_dump()` includes `discord_id` as `int` — correct - `get_creators` endpoint (line 633-635) — uses raw SQL `discord_id = %s` with int param — was already type-safe, unaffected - All other `creator_discord_id` usages — raw SQL column reads, unaffected by ORM field type **Discord snowflake range**: PostgreSQL `BIGINT` holds up to ~9.2×10^18. Current Discord snowflakes are ~1.3×10^18 — well within range, no overflow risk. ### Pre-existing (not blocking) - `custom_commands.py:697` — `Bad Token: {token}` still exposes bearer token in logs — tracked by the PR #85 pattern, but `create_creator_endpoint` was not in scope for that fix - `db_engine.py:21` — hardcoded fallback password still present — tracked by PR #84 (approved but not yet reflected in this branch)