Not a slug
Do people have a favourite id field name for what is essentially an alternate _id? For use in the frontend/url, maybe with relations? There's no other reason for it or particular logic behind how it's generated, and it is NOT a "slug". I tried just calling it "id" but that was challenging for me and my friend Cursor Tab.
18 Replies
Are you asking about a naming convention for a database column name?
Yes!
What's the construction of your URL? How does your database column get composed in that URL?
In my app ClarityText, each user has a URL like this:
https://www.claritytext.com/u/matthew-luo-9hs3
So, in the database we name a column which includes the word, slug. In your case, since you are optimizing for LLM comprehension, you can use a verbose naming convention like suffixOfSlug or something like that
So far they're random - but my choice of random. Your method is absolutely the correct use of the word "slug" https://en.wikipedia.org/wiki/Clean_URL#Slug, but mine isn't based on any human readable information
Clean URL
Clean URLs (also known as user-friendly URLs, pretty URLs, search-engine–friendly URLs or RESTful URLs) are web addresses or Uniform Resource Locators (URLs) intended to improve the usability and accessibility of a website, web application, or web service by being immediately and intuitively meaningful to non-expert users. Such URL schemes tend ...
I also just don't like seeing the word slug everywhere 😁
This is purely a semantic/style thing. I could call it anything - but I like to something short if I'm using it as much as _id. id/_id is too similar, easy to mix up
oh okay. Well, in general, I'd say do not use commonly used words as the full name of a database column, variable, etc. It is very conducive to colliding to other names, and also makes it hard for LLM's to comprehend
We once had a PR with a column named
state. That would have been pretty bad. Searching state in VS Code likely would have produced very high recall of search results with low precisionOverloaded terms are an annoyance everywhere. "key" is out of the question here. If you name something Message then you will learn a lot about practically every single library's own use of that type
Yeah, classic. Everyone feels this pain once in their career. Coding a workflow and names a column state.
Yeah, even the sample code in the Convex Stack names variables
message, body, etc. and that impeded me
Why do you want a short variable name so much?I just prefer it when it's used everywhere. And to me there isn't an obvious semantic name for it. It doesn't really matter - it's just the aesthetics I want + the overloading concern - I wanted to see if anyone had any cool ideas, and wanted to bikeshed with me 😇
oh okay, I think the more locally bounded a variable is used, the shorter it can be without causing problems
But in the era of AI, wide monitors, etc., searchability and LLM comprehension matter more than some of these other traditional factors
I think if you're going to use Convex Ents, you should particularly avoid these overloaded words
When I used Ents, i think it was easy to lose track of which column came from which table
in SQL, queries are verbose and explicit
Ents, less so
"Will LLMs understand this" is creeping into my decision making in a hard to define way. It's similar to writing clear, self-documenting code, but... they have their own quirks. Trying to make it obvious that this not eg. an express app, a react-query hook, some crazy Angular hybrid they just invented etc.
I have never encountered an LLM making such a big misunderstanding of my tech stack
But since you use Ents, there is less code for the LLM to comprehend
And you need to adhere to the Ents pluralization convention. I don't know how it handles Id. Ids, maybe
It's more for Cursor Tab/auto-complete LLMs which don't have much context, especially if you don't have existing code for them to work on. Claude doesn't have as big an issue with this. But yeah, it gets confused by ents. I started a new codebase for a new idea recently (why I'm thinking about ids) and trying life without ents again, since I kinda forgot how to write regular convex. This is where the bad suggestions are really apparent. It's so annoying to me that I had to turn it off for a while, until I'd established a basic framework it could see and mimic
Although, its always really keen on using runQuery/runMutation when it shouldn't. Pretty sure it has no actual understanding of how actions are different
Oh hmm I thinkn those are non-React patterns. The ClarityText team didn't run into that. The only issue was the suggestion to use a filter() when we actually wanted to use an index
@deen what about a shortId field with a prefix and nano id. That’s what Airtable does like “recHd7whfo79” for the record entity.
I’m assuming in convex if we wanted these additional system fields+ then we have to manually add them in on mutations, for shortIDs and updatedAt fields? In other words there’s not a way to set additional system fields that automatically are handled?
yes. there are only two system fields, _id and _creationTime
Anyway, I don't think you'd actually want this as a "system field"
You can do some very fancy stuff with custom functions + your own fields, making them "feel" like system fields. convex-ents is somewhat of an extreme exploration of this idea.