Number

Integer, approximate-number, and decimal scalar types with different precision characteristics

Scalar Types

import { s } from "viborm";

s.int(); // Required integer
s.number().nullable(); // number | null
s.decimal({ precision: 10, scale: 2 }).default("0"); // Decimal result

All three support .nullable(), .default(), .schema(), and .map(). Scalar decimals can be IDs and unique fields. Decimal lists cannot occupy any key, index, or foreign-key position. Integer and approximate-number column types can be configured via Native Types; a decimal’s required descriptor derives NUMERIC(p,s), DECIMAL(p,s), or checked scaled INTEGER directly.

Auto-Increment

s.int() (and s.bigInt()) support auto-incrementing primary keys:

s.int().id().increment(); // Auto-incrementing primary key

Examples

import { pipe, number, minValue, maxValue } from "valibot";

// Auto-incrementing ID
const id = s.int().id().increment();

// Age with validation
const age = s.int().schema(pipe(number(), minValue(0), maxValue(150)));

// Rating between 1-5
const rating = s.number()
  .nullable()
  .schema(pipe(number(), minValue(1), maxValue(5)));

// View counter with default
const views = s.int().default(0);

// Latitude/Longitude
const lat = s.number();
const lng = s.number();

Migrating from s.float()

s.float() was replaced by s.number(). The scalar’s behaviour is unchanged — it is the same approximate, finite JavaScript number, backed by the same column — so the migration is a rename in your source:

// Before
const score = s.float();

// After
const score = s.number();

There is no s.float() alias. Code that names the class or inspects scalar state has three renames:

No database migration is needed. The physical column type is unchanged: double precision on PostgreSQL, DOUBLE on MySQL, REAL on SQLite. An existing database and an existing migration snapshot both match a schema that now says s.number(), and the differ emits no operation.

Schema JSON documents spell this scalar "number" too, and a document that still says "float" is refused as an unknown type. The format is being updated before its first release, so there is no supported version 1 "float" document to migrate.

The native-type namespaces keep their database names — PG.FLOAT.DOUBLE_PRECISION, MYSQL.FLOAT.DOUBLE, SQLITE.FLOAT.REAL — because they name what the database calls the type, not what VibORM calls the scalar.