Schema analysis paralysis
I’m working on setting up a project focused around the real estate niche and I find myself getting into analysis paralysis over my schema. At the moment, it’s really the only thing that’s holding me back. Does anyone have any resources they recommend looking into to help with this problem?
15 Replies
You could turn off schema validation while you iterate
You can also make things optional while you're early on, so you can still keep some schema awareness and not have to turn it off completely - your schema doesn't have to be a commitment until you want it to be.
Also, ask o1 and Sonnet 3.5 for advise
jot down enough schema to get you to the next milestone
@doug I often, weirdly enough, find the first few tables ther hardest to write
then things get easier
to avoid paralysis, I often start without a schema and just throw some documents in there
liberally use convex's "delete table data" feature on the dashboard and iterate again
once it feels like i'm really now starting to develop my app instead of just come up with the start of the data model, I use the dashboard's schema generation to give me my first schema. and I usually find it easier to extend it from there
so that's my personal advice in the start of projects. if you're not quite sure what you're making yet, maybe just YOLO some records in there instead of making a type specification first
ah yeah, that "YOLO some records" is also what i mean by "jot down enough schema" in my workflow
is there a global way of doing this besides wrapping everything in v.optional()
I don't think so. I was talking about the defineSchema() funciton
as opposed to individual table columns
Disabling schema validation as Matt mentioned is effectively the global alternative to wrapping everything in v.optional().
https://docs.convex.dev/database/schemas#schemavalidation-boolean
Ah there it is, got it. Thanks
I'm also a fan of some strategic
v.any()
s -- like myTable: { fieldImSureAbout: v.string(), metadata: v.any() }
or even tableIDontHaveASolidSchemaForYet: v.any()
Oh yeah, I recall you mentioning that earlier. I suppose the benefit of that is that you get Intellisense and autocomplete that that table exists.
I think since switching to cursor i'm even less worried about schema changes as its even faster to refactor in pre production.
- Having a validator variables and use them in the schema
- Unique names for global find and replace.
- Using ents with edges forces you to consider a structured design create relationships.
- Anytime if you think a table is too big it probably is.
- Assume you will get it wrong and refactor everything a few times anyway.
Globally unique column names is actually really useful
I just wanted to thank everyone for their thoughts on this. I decided to stop thinking about it and just build out my front end so that I could focus on the UX of the people who will eventually be filling out my forms. Many of you were correct taking this approach. I’m getting a clear picture of what the final schema should look like.
A major benefit of Convex is precisely not having to think about this stuff early on. Hard to not do though, muscle memory.