Skip to main content
Objetos personalizados são novos tipos de registro que o seu app adiciona a um espaço de trabalho — cartão‑postal, fatura, assinatura, qualquer coisa específica do seu domínio. Cada objeto declara seu esquema (campos, relações, valores padrão) e um identificador universal estável que persiste entre sincronizações e implantações.
src/objects/post-card.object.ts

​
Pontos-chave

  • O universalIdentifier deve ser exclusivo e estável entre implantações.
  • Cada campo requer name, type, label e seu próprio universalIdentifier estável.
  • O array fields é opcional — você pode definir objetos sem campos personalizados.
  • Campos inline definidos aqui não precisam de objectUniversalIdentifier — ele é herdado do objeto pai. Use defineField() para adicionar campos a objetos que não pertencem a você.
  • Você pode criar novos objetos com yarn twenty dev:add object, que orienta você na definição de nomes, campos e relacionamentos. Veja Arquitetura → Scaffolding de entidades.
Os campos base são adicionados automaticamente. Quando você define um objeto personalizado, o Twenty cria campos padrão como id, name, createdAt, updatedAt, createdBy, updatedBy e deletedAt para você. Você não precisa declará‑los no seu array fields — apenas seus campos personalizados. Você pode substituir um campo padrão declarando um com o mesmo nome, mas isso raramente é uma boa ideia.

​
Tipos de campo

O conjunto completo de valores de FieldType, exportados de twenty-sdk/define: Tipos compostos armazenam vários subcampos (por exemplo, FULL_NAME = primeiro + último nome; CURRENCY = amountMicros + currencyCode). SELECT e MULTI_SELECT exigem um array options, como no exemplo acima.

​
Valores padrão

Valores padrão de strings literais devem ser colocados entre aspas simples dentro da string — defaultValue: "'Draft'", não defaultValue: "Draft". É por isso que o campo status acima usa `'${PostCardStatus.DRAFT}'`. Strings sem aspas são reservadas para valores padrão computados, avaliados quando um registro é criado:
  • 'uuid' — gera um UUID (para campos UUID)
  • 'now' — o carimbo de data/hora atual (para campos DATE_TIME)
A mesma convenção se aplica a subcampos de string de valores padrão compostos (por exemplo, { source: "'MANUAL'" } em um campo ACTOR) e a valores de SELECT/MULTI_SELECT. Uma string literal padrão deixada sem aspas gera um aviso quando seu app é compilado.

​
Nulabilidade

isNullable controla se um campo aceita NULL. O valor padrão é true — omita-o para campos opcionais. Defina isNullable: false para tornar um campo obrigatório no nível do banco de dados. Alterações em isNullable são aplicadas em todas as sincronizações, incluindo sincronizações que atualizam um campo existente — assim, você pode alternar a nulabilidade de um campo editando o manifesto e sincronizando novamente.
Tornar um campo existente obrigatório requer um valor padrão. Quando você altera um campo para isNullable: false, também deve fornecer um defaultValue não nulo. O valor padrão preenche retroativamente quaisquer linhas NULL existentes antes de a restrição NOT NULL ser aplicada; sem ele a sincronização falha com Default value cannot be null for non-nullable fields. Campos de relação e campos TS_VECTOR sempre aceitam nulos, portanto isNullable não tem efeito sobre eles.

​
O que vem depois