Input Type Generation

This page documents the make:input command, which generates GraphQL input type classes from database schema definitions. Input types provide structured validation and type safety for GraphQL mutations and are automatically derived from table column definitions in db.json.

For model class generation, see Model Generation. For controller generation that uses these input types, see Controller Generation. For the database schema format, see Database Schema (db.json).

---

Overview

Input types in GraphQL serve as parameter containers for mutations, providing type safety and validation at the API boundary. The Light framework generates these input type classes automatically from database schema definitions, ensuring consistency between database structure and API contracts.

Input Type Generation Flow: The CLI reads table definitions from db.json, generates input classes with typed properties matching column definitions, and applies validation constraints based on column attributes (nullable, length, type).

Sources: bin/light1-24 db.json1-676

---

Command Registration

The make:input command is registered in the Light CLI tool alongside other code generation commands.

Command Class	Purpose	Registration Line
MakeInputCommand	Generate input validation classes	bin/light8 bin/light20
MakeModelCommand	Generate model classes	bin/light9 bin/light19
MakeControllerCommand	Generate controller classes	bin/light7 bin/light18
MakeTsCommand	Generate TypeScript definitions	bin/light10 bin/light21

Sources: bin/light1-24

---

Input Type Purpose

Input types solve several critical problems in GraphQL API development:

Type Safety

GraphQL mutations require strongly-typed input parameters. By generating input classes from database schemas, the framework ensures that mutation arguments match the underlying data structure.

Validation

Input types encapsulate validation rules derived from database constraints:

• Nullable fields → Optional properties
• VARCHAR lengths → String length validation
• Numeric types → Type coercion and range validation
• Foreign keys → Reference validation

Code Consistency

Manual input type creation is error-prone and becomes outdated as schemas evolve. Generated input types remain synchronized with database definitions.

GraphQLite Integration

The GraphQLite library uses PHP type hints and annotations on input classes to automatically build GraphQL input object types in the schema.

Sources: Context from high-level diagrams

---

Schema Source Format

Input generation reads table definitions from db.json. Each table definition contains columns with attributes that drive input type generation.

Example Schema Definition

The User table definition demonstrates the schema structure:

Key Schema Attributes:

Attribute	Effect on Input Type
name	Property name (snake_case → camelCase)
type	PHP type hint (varchar→string, int→int, json→array)
length	@Assert\Length(max=...) annotation
nullable	Nullable PHP type (?string vs string)
unsigned	@Assert\PositiveOrZero or @Assert\Positive
default	Optional property with default value
auto_increment	Excluded from input (server-assigned)

Sources: db.json1-138 (User table definition)

---

Generated Input Structure

Input classes follow a consistent structure with PHP 8 typed properties and validation annotations.

Property Type Mapping

The generator maps database column types to PHP types:

Excluded Fields

Certain columns are automatically excluded from input types:

Column Pattern	Reason for Exclusion
auto_increment: true	Server-assigned identifiers
created_time	Auto-populated by audit system
updated_time	Auto-populated by audit system
created_by	Auto-populated from auth context
updated_by	Auto-populated from auth context

These fields are managed by the Light\Model base class and should not be provided by clients.

Sources: db.json4-127 Context from Data Layer

---

Validation Annotations

Generated input classes include Symfony Validator annotations derived from schema constraints.

String Validation

For VARCHAR and TEXT columns:

Sources: db.json13-16 (username column definition)

Numeric Validation

For INT and TINYINT columns:

Sources: db.json58-63 (status column definition)

Date and Time Validation

For temporal columns:

Sources: db.json75-78 (join_date column), db.json116-118 (created_time column)

JSON Validation

For JSON columns:

Sources: db.json85-87 (setting column)

---

Foreign Key Handling

Foreign key columns in the schema become reference properties in input types.

The generator creates standard integer properties for foreign key columns. Reference validation is typically enforced at the database level via foreign key constraints, but additional application-level checks can be added in mutation resolvers.

Sources: db.json180-230 (UserRole table with foreign key)

---

Integration with GraphQL Mutations

Generated input types are used as parameters in GraphQL mutation methods.

Mutation Method Pattern

Controller Usage Example

A typical mutation controller method signature:

GraphQLite automatically:

1. Maps GraphQL input object to UserInput instance
2. Validates via Symfony Validator annotations
3. Passes validated input to mutation method
4. Serializes returned User model to GraphQL type

Sources: Context from GraphQL API, Controllers

---

Command Usage

While the specific implementation details of MakeInputCommand are not visible in the provided files, the command follows the standard Symfony Console command pattern.

Expected Command Invocation

Expected Output Location

Generated input classes typically follow a namespace convention:

src/
 Input/
 UserInput.php
 RoleInput.php
 ConfigInput.php
 ...

Each input class corresponds to a table in db.json and is named with an Input suffix.

Sources: bin/light20 (command registration)

---

GraphQL Schema Integration

Generated input types become GraphQL input object types in the schema.

GraphQL Schema Example:

The exclamation marks (!) indicate non-nullable fields, derived from the nullable: false attribute in db.json.

Sources: Context from GraphQL API, Schema Generation and Type System

---

Validation Error Handling

When validation fails, GraphQLite converts Symfony Validator errors into GraphQL error responses.

Validation Flow

Error Response Structure

Validation errors are returned in the standard GraphQL error format:

Sources: Context from GraphQL Integration

---

Custom Validation Rules

Beyond auto-generated constraints, developers can add custom validation logic.

Input Class Extension

Generated input classes can be manually extended with additional validation annotations:

Mutation-Level Validation

Complex validation logic that spans multiple fields or requires database queries should be implemented in the mutation resolver:

Sources: Context from Controllers, Authentication and Authorization

---

Relationship to Models

Generated input types are distinct from model classes but share structural similarities.

Input vs Model Comparison

Aspect	Input Class	Model Class
Purpose	Data transfer, validation	Data persistence, business logic
Base Class	None (POJO)	Light\Model
Properties	Public typed properties	Protected with getters/setters
Annotations	@Assert\* validators	@Type, @Field for GraphQL
Auto-populated	No (client-provided)	Yes (created_by, updated_by)
Primary Key	Excluded	Included

The separation ensures that:

• Clients cannot inject audit fields (created_by, updated_by)
• Primary keys are server-assigned
• Business logic remains in models, not input classes

Sources: Context from Data Layer, Base Model Class

---

Update vs Create Inputs

Some systems generate separate input types for create and update operations.

Create Input

Contains all required fields except auto-generated ones:

• No primary key
• All non-nullable fields required
• Audit fields excluded

Update Input

All fields optional to support partial updates:

• Nullable types for all properties
• Only changed fields provided by client
• Primary key passed separately as mutation argument

Example Pattern

The Light framework's code generation strategy (whether it generates separate create/update inputs or a single input type) is determined by the MakeInputCommand implementation.

Sources: Context from Controllers, GraphQL Integration

---

Best Practices

Regeneration Strategy

Input types should be regenerated whenever db.json changes:

1. Modify schema in db.json
2. Run php bin/light make:input --all
3. Review generated changes
4. Add custom validation if needed
5. Update mutation resolvers

Custom Validation Placement

Validation Type	Location
Field format (email, URL)	Input class annotation
Field length/range	Input class annotation (auto-generated)
Uniqueness checks	Mutation resolver
Business rules	Mutation resolver or service layer
Cross-field validation	Input class custom validator or resolver

Namespace Organization

src/
 Input/ # Generated input types
 Type/ # GraphQL output types
 Controller/ # Mutation resolvers
 Model/ # Database models

Keep input types in a dedicated namespace to distinguish them from GraphQL output types and database models.

Sources: Context from overall architecture

---

Summary

The make:input command generates GraphQL input type classes from db.json schema definitions, providing type safety and validation for mutations. Key characteristics:

• Source: Table definitions in db.json1-676
• Command: MakeInputCommand registered at bin/light20
• Output: PHP classes with typed properties and validation annotations
• Purpose: Strongly-typed, validated mutation parameters
• Integration: GraphQLite converts to GraphQL input object types
• Validation: Symfony Validator annotations enforce constraints

Generated input types accelerate development by maintaining consistency between database schema and API contracts, while providing extensibility for custom validation rules.