Skip to main content

Concepts

Field Types

How each Prisma field type is rendered in admin forms, what an empty value writes, and which types the admin does not edit.


sveltekit-admin inspects each field’s Prisma type to decide how to render it in create/edit forms, and how to convert what was submitted back into a value for the column.

Supported field types

Prisma type Form input
String text input (textarea when the name contains description, content, body or bio)
Int, BigInt number input
Float, Decimal number input
Boolean checkbox
DateTime datetime-local input
Json textarea holding the JSON
enum <select> listing the values declared in the schema

Relations are not in this table — a foreign key is rendered from the relation graph, not from its scalar’s type. See Relations.

What an empty field writes

A field that is present in the submitted form but left empty writes null, whatever its type. A field that is absent from the submission writes nothing at all, and the column keeps its current value.

That distinction is what separates “the user cleared this” from “this was never submitted”. A readonly field, a field hidden through models[].hidden, and a column with a @default (which the create form does not render) all fall in the second case.

If the column is declared non-nullable, an empty value is refused with a 422 and <field> is required shown on the field itself — the form comes back with everything you typed still in place. Two exceptions, both deliberate:

  • a column filled in by models[].scope is imposed by the server rather than refused, so a model whose tenant column is required and visible stays creatable from the admin;
  • an empty required relation is reported on the relation (author is required), not on its scalar (authorId).

Values that cannot be converted

A value that cannot be turned into the column’s type — for example unparseable JSON, or a numeric value that produces NaN — is refused the same way, with <field>: invalid value on the field. Nothing is written.

Numeric values currently use JavaScript parseInt/parseFloat; malformed partial strings such as 12abc may therefore be coerced to 12 rather than rejected. Invalid DateTime text is passed through to the adapter and may be rejected there. Treat these as current conversion limitations, not strict input validation.

Types the admin does not edit

Bytes is not rendered in forms. There is no meaningful HTML input for binary data, and the text input it used to fall back to could never work: the driver expects a Uint8Array and receives a string. A model with a required Bytes column cannot be created from the admin — manage that column from your own application code.

Two precision limits worth knowing, since neither raises an error:

  • BigInt goes through parseInt, so a value above 2^53 - 1 (9007199254740991) loses precision on its way to the column. Values within that range are exact.
  • Decimal goes through parseFloat, so it is subject to the usual binary floating-point rounding. If you are storing money and need exact decimal semantics, do not edit that column from the admin.

Automatic hiding of sensitive fields

Any field whose name contains password, hash, secret or token (case-insensitive) is treated as sensitive. This covers hashedPassword, passwordHash and refreshToken with no configuration.

  • Sensitive-looking String columns are excluded by default from list views, search, filters, audit payloads and edit forms. An explicit listFields entry can override a false positive for list display, but hidden always wins. Sensitive values still remain excluded from search, filters and audit payloads. The create form still offers the field because nothing is stored yet to leak.
  • Only String columns are affected. The match is on substrings, so without that restriction an Int named tokenCount or hashtagCount would have become uneditable. Those stay visible and editable.
  • If the heuristic gets a String field wrong, list it explicitly in that model’s listFields (see Model Configuration) to bring the column back in list views. Use models[].hidden to remove a field from the admin entirely, everywhere.

The admin writes what is typed straight to the column, with no hashing. Setting a password from the create form stores it in plaintext, which will not match an application using bcrypt or better-auth. Put the field in models[].hidden and manage credentials in your own app.