gabrielw•4mo ago

Hey all, does anyone know if there is a Table helper equivalent for convex ENTs?

Trying to see if it's possible to collocate validators with schema definitions using the ENTs abstraction. For example, I am currently using the defineEnts method to define a table in my schema:

events: defineEnt({
      name: v.string(),
      event_img_storage_id: v.optional(v.id("_storage")),
      event_img_url: v.optional(v.string()),
    })
      .field("start_at", v.string(), { index: true })
      .field("timezone", v.string())
      .field("end_at", v.optional(v.string()))
      .field("geo_address_json", v.optional(geo_address_json_validator))
      .field("geo_latitude", v.optional(v.string()))
      .field("geo_longitude", v.optional(v.string()))
      .field("luma_event_id", v.optional(v.string()))
      .edges("teams"),...

events: defineEnt({
      name: v.string(),
      event_img_storage_id: v.optional(v.id("_storage")),
      event_img_url: v.optional(v.string()),
    })
      .field("start_at", v.string(), { index: true })
      .field("timezone", v.string())
      .field("end_at", v.optional(v.string()))
      .field("geo_address_json", v.optional(geo_address_json_validator))
      .field("geo_latitude", v.optional(v.string()))
      .field("geo_longitude", v.optional(v.string()))
      .field("luma_event_id", v.optional(v.string()))
      .edges("teams"),...

And I am exporting a separate obj in order to infer argument validation for the corresponding create mutation:

// supplied for frontend mutation
export const eventFields = {
  name: v.string(),
  start_at: v.string(),
  timezone: v.string(),
  end_at: v.optional(v.string()),
  geo_address_json: v.optional(geo_address_json_validator),
  geo_latitude: v.optional(v.string()),
  geo_longitude: v.optional(v.string()),
  team_ids: v.array(v.id("teams")),
  event_img_storage_id: v.optional(v.id("_storage")),
};

// supplied for frontend mutation
export const eventFields = {
  name: v.string(),
  start_at: v.string(),
  timezone: v.string(),
  end_at: v.optional(v.string()),
  geo_address_json: v.optional(geo_address_json_validator),
  geo_latitude: v.optional(v.string()),
  geo_longitude: v.optional(v.string()),
  team_ids: v.array(v.id("teams")),
  event_img_storage_id: v.optional(v.id("_storage")),
};

Just wondering if there is a way to declare the validator once and feed it into the schema with the ENT-way of doing things. As outlined in the best practices of not redefining the shape in vanilla convex:

// in convex/schema.ts
// ...
export const recipeFields = {
  name: v.string(),
  course: courseValidator,
  ingredients: v.array(v.string()),
  steps: v.array(v.string()),
};

export default defineSchema({
  recipes: defineTable(recipeFields)
    .index("by_course", ["course"]),
});

// in convex/schema.ts
// ...
export const recipeFields = {
  name: v.string(),
  course: courseValidator,
  ingredients: v.array(v.string()),
  steps: v.array(v.string()),
};

export default defineSchema({
  recipes: defineTable(recipeFields)
    .index("by_course", ["course"]),
});

22 Replies

Convex Bot•4mo ago

Thanks for posting in <#1088161997662724167>. Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets. - Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.) - Use search.convex.dev to search Docs, Stack, and Discord all at once. - Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI. - Avoid tagging staff unless specifically instructed. Thank you!

ampp•4mo ago

I don't think there is a way to do this, otherwise i should rewrite a lot of my schema. I just define most of it the old way. The only issue would be when using unique: true I do vaugely recall this being talked about somewhere here in discord...

deen•4mo ago

I ended up minimizing my use of .field definitions due to losing this convenience, especially if you're using return type validators. You can still use regular index definitions, and I only use field for the fancy stuff like unique and default, or for fields that I don't usually want in public validators anyway (eg. updatedAtTime). I'd still definitely recommend colocating your ent definitions with related validators/functions - if you make good use of the convex helper utils, you can vastly cut down on repetitive code, and easily keep your validators in sync if you change your schema. My convex/schema.ts file has very few actualy ent defininitions in it - they're all imported from their domain areas across the app.

gabrielwOP•4mo ago

this all makes sense - I like your approach. Thanks for clarifying and for the example! Appreciate it.

i.sona•4mo ago

In my case i extended convex-ents by adding an updateField function in the entitydefinition class that does not throw an exception when a field already exists , using this in place of field, i can pass all fields into the Table helper call , and still define attributes like unique,defualt and index the way i do currently and it works without issues . Am going to do a PR to convex-ents maybe they accept it . for now am using convex-ents off of my github branch

ampp•4mo ago

Nice, you probably have a good chance for PR, i look forward to it 🙂

i.sona•4mo ago

Cool. I will push it

ampp•4mo ago

Yeah, probably a good idea to drop a link to it in #convex-ents also

i.sona•4mo ago

in Action

ampp•4mo ago

Hmm, i think the only friction would be having to maintain the string() part in two places, maybe something like .fieldProps('teamname', { unique: true }) makes it a bit more clear? or addFieldProps/features.. assuming it is better language, i don't exactly see a label in the docs for that data within { }

i.sona•4mo ago

I can modify that . I dont get the line "i don't exactly see a label in the docs for that data within { }" . are you referring to the PR ?

ampp•4mo ago

I was looking in the ents docs to see if { default,index,unique } has a name like properties etc, but its probably only referenced in code

i.sona•4mo ago

if you look at the type definition for field (and updateField which is currently thesame), option (the object {}) has a type with 3 optional properties : default,unique and index

ampp•4mo ago

lol, yeah duh.. options.. maybe just .options('fieldName', { options })

i.sona•4mo ago

or .fieldOptions ?

ampp•4mo ago

Yeah, that's probably best. Ill be happy to use it however 🙃 - i'm already doing a lot of like what dean is doing, but still got many more tables to update. It would definitely make rewriting ai-town to ents much faster...😅

i.sona•4mo ago

yeah it would.

i.sona•4mo ago

PR is in and updated

i.sona•4mo ago

OK, am running into an issue at runtime , where the fieldPath for fieldOptions are missing causing queries to fail. Am looking at that

gabrielwOP•3mo ago

Thanks @deen , in regards to collocating validtors within different files, and importing them into the schema, I seem to be having some Uncaught TypeErrors when I try to export validators say from an events.ts file, into the schema.ts. I have my defineEnt args all within the schema.ts , just trying to collocate the validators. Interestingly, when I declare the validators within the schema.ts file, I am able to use them within the ent definitions without issues. Is this something you came accross?

deen•3mo ago

It's easy to cause circular import loops when using ents. I don't know why it happens exactly, but typescript has to run through a rube goldberg machine to calculate them - and they become intertwined with the regular convex types on the way. I found that declaring them in the same file as any convex functions (query/mutation/action) would cause the issue. So I only ever declare validators/ents in their own file, while being very careful with what to import. In my example I only import convex ents/utils related to creating the entity shape, constants which import nothing else themselves, and other validators from files which follow the same pattern. Consider these modules the source of truth of your data model. Keep a tree-like structure, with your ents and validators as the leaves, which all feed down to schema.ts at the root. Anything that needs to use the validators is free to import whatever they want - just don't import the other way.

gabrielwOP•3mo ago

ah thanks @deen . 🔥 I was curious about this pattern, since I saw elsewhere on discord that it was recommended to collocate all api functions in a single file, like an events.ts, instead of separate queries/mutations files. And so with this pattern, I found myself declaring validators, and also exporting the convex function handlers. I suppose the ents do introduce an additional abstraction that should be reflected at the filesystem level (ie, the tree-like structure). So I will nest something like a validators.ts and handlers.ts file within an events folder for example, and this should both resolve the type errors and organize the code nicely.

Hey all, does anyone know if there is a Table helper equivalent for convex ENTs?

Did you find this page helpful?