Varchar limits are probably too low and/or need better enforcement #26
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
High Priority
invalid
question
reproduction needed
schema-fix-required
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ClassClock/API#26
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
github.com/MoralCode/ClassClockAPI@fa35cfe710/common/db_schema.py (L46)as an example of the one that was causing issues (edit: its the 20 character limit on BellScheduleDisplayName thats causing issues)it seems this is currently being enforced/caught at the sqlalchemy layer by as a DataError. which is probably a dumb way to do it
pending further evaluation and root-causing as the affected column (
(mysql.connector.errors.DataError) 1406 (22001): Data too long for column 'bell_schedule_display_name' at row 1) wasnt being given a string that was too long (only 27 ASCII characters). This will also likely require a schema changeSentry incident refs: CLASSCLOCK-API-7 CLASSCLOCK-API-9
can confirm this crash is replicable when the display name is too long (such as "this is a really long display name for testing purposes")
added client side validation in
github.com/MoralCode/ClassClock@47ffde16ceto make this less likely to happen. still needs to be fixed at the schema level though