Saltar al contenido principal
Los objetos personalizados son nuevos tipos de registro que tu aplicación añade a un espacio de trabajo — Tarjeta postal, Factura, Suscripción, cualquier cosa específica de tu dominio. Cada objeto declara su esquema (campos, relaciones, valores predeterminados) y un identificador universal estable que se mantiene a través de sincronizaciones e implementaciones.
src/objects/post-card.object.ts

Puntos clave

  • El universalIdentifier debe ser único y estable entre implementaciones.
  • Cada campo requiere name, type, label y su propio universalIdentifier estable.
  • La matriz fields es opcional: puedes definir objetos sin campos personalizados.
  • Los campos en línea definidos aquí no necesitan un objectUniversalIdentifier, ya que se hereda del objeto padre. Usa defineField() para añadir campos a objetos que no te pertenecen.
  • Puedes generar nuevos objetos con yarn twenty dev:add object, que te guía en la asignación de nombres, los campos y las relaciones. Consulta Arquitectura → Generación de entidades.
Los campos base se añaden automáticamente. Cuando defines un objeto personalizado, Twenty crea campos estándar como id, name, createdAt, updatedAt, createdBy, updatedBy y deletedAt por ti. No necesitas declararlos en tu matriz fields, solo tus campos personalizados. Puedes sobrescribir un campo predeterminado declarando uno con el mismo nombre, pero esto rara vez es una buena idea.

Tipos de campo

El conjunto completo de valores de FieldType, exportados desde twenty-sdk/define: Los tipos compuestos almacenan múltiples subcampos (por ejemplo, FULL_NAME = nombre + apellido; CURRENCY = amountMicros + currencyCode). SELECT y MULTI_SELECT requieren un arreglo options como en el ejemplo anterior.

Valores predeterminados

Los valores predeterminados de cadenas literales deben ir entre comillas simples dentro de la cadena — defaultValue: "'Draft'", no defaultValue: "Draft". Por eso el campo status anterior utiliza `'${PostCardStatus.DRAFT}'`. Las cadenas sin comillas se reservan para valores predeterminados calculados, evaluados cuando se crea un registro:
  • 'uuid' — genera un UUID (para campos UUID)
  • 'now' — la marca de tiempo actual (para campos DATE_TIME)
La misma convención se aplica a los subcampos de tipo cadena de los valores predeterminados compuestos (por ejemplo, { source: "'MANUAL'" } en un campo ACTOR) y a los valores de SELECT/MULTI_SELECT. Un valor predeterminado de tipo cadena literal dejado sin comillas genera una advertencia cuando se compila tu aplicación.

Nulabilidad

isNullable controla si un campo acepta NULL. Su valor predeterminado es true — omítelo para campos opcionales. Configura isNullable: false para hacer que un campo sea obligatorio a nivel de base de datos. Los cambios en isNullable se aplican en cada sincronización, incluidas las sincronizaciones que actualizan un campo existente; de este modo, puedes cambiar la nulabilidad de un campo editando el manifiesto y sincronizando de nuevo.
Hacer que un campo existente no acepte valores nulos requiere un valor predeterminado. Cuando cambies un campo a isNullable: false, también debes proporcionar un defaultValue no nulo. El valor predeterminado rellena cualquier fila NULL existente antes de que se aplique la restricción NOT NULL; sin él, la sincronización falla con Default value cannot be null for non-nullable fields. Los campos de relación y los campos TS_VECTOR siempre aceptan valores nulos, por lo que isNullable no tiene ningún efecto en ellos.

¿Qué sigue?