Repository navigation
Titles and Names Longer Than 36 Characters Cause An Error #295
Description
Describe the bug
A user is limited to 36 characters on any entity in the documents table/collection in the database (songs, setlists, etc.). In addition, the URL slug is tied to the ID. If I want to edit the name of a setlist, I noticed the code in SetlistSet.vue attempts to create a new entity with the updated name, copies the data from the old entity into the new one, and then deletes the old entity.
To Reproduce
Steps to reproduce the behavior:
- With at least 1 song already in the database, in the left-hand navigation pane, click the + button beside SETLIST.
- Complete all required fields and make the Title more than 36 characters.
- Click Create Setlist button in lower, right-hand corner
- Observe error toast in the lower, right-hand corner with text: "bad-request Invalid document id for the collection setlists"
Expected behavior
A reasonably long title length (256-512?) is stored in the database.
Screenshots
Desktop (please complete the following information):
- OS: Windows 11
- Browser: Edge
- Version: 154.0.4258.37
Additional context
The song title/setlist name truncation is caused by the varchar(36) data type on the documents.id column (see screenshot above).
Reacted by Andreas
Activity
Audiosyncrasy commentedon Sep 28, 2026
@devmount , I wasn't sure if a "bug" was the correct classification for this issue, but it seems like the URL slugs are coupled with the unique identifiers for all documents (songs, setlists, etc.). I would propose moving the slug into the
datacolumn (JSON collection) and updating the code to save the id as a generated GUID and reference thedocuments.data.slugfield to get the URL slug when you need it in the frontend.Is there anything I'm missing in my assessment of how the code works?
[-]Titles and Names More Than 36 Characters Cause An Error[/-][+]Titles and Names Longer Than 36 Characters Cause An Error[/+]EinEnton commentedon Sep 29, 2026
You are correct @Audiosyncrasy that the id is right now used to store the slug. The database scheme is limited to a reasonable size more focused towards GUIDs since it is using it heavily in indexes. I agree that the slug should be more human and less machine facing. Maybe there is a middleground by creating a stable hash from the slug (for migration purposes). @devmount is the slug as an ID used for something more advanced than referencing it from a setlist and therefore being an easier migration scenario? If yes I would volunteer to write a migration script that does the one time lookup and replacement ;-)
devmount commentedon Sep 29, 2026
Thanks @Audiosyncrasy for creating that issue! Generating the slugs from the titles was a design decision I made like a decade ago 😅 and while I love having those readable URLs, I'm now more and more thinking about decoupling that.
@EinEnton The slug/ID is just generated from the title on creation and update when changing that title for setlists. For songs it's the same but its implementation is wip for a long time 😂 (you cannot update the title after creation iirc). So we could just use Ambers generated IDs and have a custom slug field (without char limit) that can be set. I'd need to think a bit about the impact, but you're very welcome to write a migration script once we have specified that.