sujayakar has demo code that does
@sujayakar has demo code that does exactly that. it's really slick, but i'm not sure if/when we would be able to ship it
6 Replies
yep! we have the new type inference algorithm working but (1) need to integrate it and (2) need to make some product decisions (curious what you think here @cyremur).
for example, it might be a bit jarring to go and infer string literals when that isn't the developers intent and instead they're getting user data shown directly in the generated schema. for example, if a
user
table has an email
field but there are only, say, 5 rows in the table, we'd generate a v.union
of v.literal
s of each of the user's emails!
one idea I had was to default to not inferring literals (i.e. the current behavior of v.string
) and then have an interaction to instantly "refine" the type in the generated schema view if desired. thoughts?ok some reference info for the use case
so this is great inference
this is the truth
now I wouldn't except it to guess
source.abilities
cause that's a lot honestly but source.type
should be simple enough
my user-in-your-face approach to this would be to highlight this on the generated schema page as a potential enumthis would be how I'd try to convey it to the user

love it! yeah I like the framing as "potential enum" for exploration.
we haven't decided on constants yet, but we'd be able infer unions up to a set length (say, 16). in your example, abilities would "overflow" to just
v.string()
without the ability to infer a potential enum.on another note, is there away to use
v.object({...}).type
in a typedef? trying to get to single source of truth with the schema.tsArgument Validation | Convex Developer Hub
Argument validators ensure that queries,