Notification Table Migration

Purpose and Scope

This document explains the make:notifications-table command, which generates a database migration for storing notifications in the application. This migration creates the infrastructure needed to support database-backed notifications, allowing the framework to persist notification data for later retrieval or marking as read.

This page specifically covers the notifications table migration generator. For other database infrastructure migrations, see Cache System Table Migrations, Session Table Migration, and Queue System Table Migrations. For information about generating notification classes themselves, see Event System Generators.

Sources: src/Generator/NotificationTableCommand.php1-84

---

Command Overview

The NotificationTableCommand class implements the notifications table migration generator. This command is registered under the name make:notifications-table with an alias notifications:table.

Class Structure

Aspect	Implementation
Base Class	Hyperf\Devtool\Generator\GeneratorCommand
Command Name	make:notifications-table
Alias	notifications:table
Namespace	Hypervel\Devtool\Generator
Stub File	stubs/notifications-table.stub

The command extends the base generator infrastructure provided by Hyperf, inheriting common functionality for file generation, directory creation, and IDE integration.

Sources: src/Generator/NotificationTableCommand.php13-26

---

Command Registration Flow

Sources: src/Generator/NotificationTableCommand.php1-84

---

Execution Flow

The command follows a standard migration generation pattern with timestamp-based naming:

Key Implementation Details

1. Timestamp Generation: The migration filename uses Carbon::now()->format('Y_m_d_000000') to create a sortable timestamp src/Generator/NotificationTableCommand.php33

2. Path Resolution: The command accepts a --path option, defaulting to database/migrations/{filename} src/Generator/NotificationTableCommand.php34

3. Existence Check: Uses alreadyExists() to prevent accidental overwrites unless --force is specified src/Generator/NotificationTableCommand.php39-42

4. Direct Copy: Unlike other generators that perform placeholder replacement, this command directly copies the stub content src/Generator/NotificationTableCommand.php49

Sources: src/Generator/NotificationTableCommand.php28-56 src/Generator/NotificationTableCommand.php63-66

---

Command Usage

Basic Syntax

With Alias

Command Options

Option	Shorthand	Type	Description
--path	-p	Optional	Custom path for the migration file
--force	-f	Boolean	Overwrite existing migration file

Usage Examples

Sources: src/Generator/NotificationTableCommand.php73-78 src/Generator/NotificationTableCommand.php17-23

---

Generated Migration Structure

The generated migration creates a notifications table optimized for storing polymorphic notification data. The migration uses the Hypervel migration framework and schema builder.

Migration Class Structure

Sources: src/Generator/stubs/notifications-table.stub1-32

---

Table Schema Definition

The notifications table is designed to store notifications with support for polymorphic relationships and read tracking.

Schema Overview

Column Specifications

Column	Type	Constraints	Purpose
id	uuid	Primary Key	Unique identifier for each notification using UUID format
type	string	Not Null	Fully qualified class name of the notification (e.g., App\Notifications\InvoicePaid)
notifiable_type	string	Not Null	Polymorphic type column storing the model class that receives the notification
notifiable_id	bigint	Not Null	Polymorphic ID column storing the model instance ID that receives the notification
data	text	Not Null	JSON-serialized payload containing notification data
read_at	timestamp	Nullable	Timestamp indicating when the notification was marked as read (NULL if unread)
created_at	timestamp	Not Null	Record creation timestamp (auto-managed)
updated_at	timestamp	Not Null	Record update timestamp (auto-managed)

Polymorphic Relationship

The morphs('notifiable') method creates two columns for polymorphic relationships:

• notifiable_type: Stores the model class name (e.g., App\Models\User)
• notifiable_id: Stores the model instance ID

This allows notifications to be sent to any model type (users, teams, organizations, etc.) without requiring separate tables.

Sources: src/Generator/stubs/notifications-table.stub15-21

---

Stub Template Analysis

The migration stub contains a complete, ready-to-use migration class:

Stub Structure

Key Design Decisions

1. UUID Primary Key: Uses UUIDs instead of auto-incrementing integers for globally unique identifiers across distributed systems src/Generator/stubs/notifications-table.stub16

2. No Placeholder Replacement: The stub requires no variable substitution, enabling direct file copy src/Generator/NotificationTableCommand.php49

3. Nullable Read Tracking: The read_at column is nullable to distinguish between read and unread notifications src/Generator/stubs/notifications-table.stub20

4. Text Storage for Data: Uses text type for the data column to accommodate large JSON payloads src/Generator/stubs/notifications-table.stub19

Sources: src/Generator/stubs/notifications-table.stub1-32

---

Integration with Notification System

The generated migration supports the database notification channel, which is part of the framework's notification broadcasting system.

Notification Workflow

Usage Pattern

Once the migration is executed, notifications can be stored using:

Sources: src/Generator/stubs/notifications-table.stub15-21

---

File Generation Details

Filename Convention

The generated migration file follows the Laravel migration naming convention:

YYYY_MM_DD_000000_create_notifications_table.php

• Date Prefix: Carbon::now()->format('Y_m_d_000000') ensures chronological ordering
• Constant Time: Uses 000000 for the time component, placing it at the start of the day
• Descriptive Suffix: _create_notifications_table.php clearly indicates the migration's purpose

Default Output Location

BASE_PATH/database/migrations/YYYY_MM_DD_000000_create_notifications_table.php

Sources: src/Generator/NotificationTableCommand.php33-34

---

Configuration and Customization

Stub Path Configuration

The command supports custom stub paths via configuration:

The stub resolution order:

1. Custom path from $this->getConfig()['stub']
2. Default path: __DIR__ . '/stubs/notifications-table.stub'

This allows framework users to override the default stub template by providing a custom configuration.

Sources: src/Generator/NotificationTableCommand.php58-61

---

Command Lifecycle Methods

Method Reference Table

Method	Return Type	Purpose
__construct()	void	Sets command name to make:notifications-table
configure()	void	Sets description, aliases, and inherits parent options
execute()	int	Main execution logic - generates migration file
getStub()	string	Returns path to stub template
alreadyExists()	bool	Checks if migration file already exists
getArguments()	array	Returns empty array (no positional arguments)
getOptions()	array	Returns command options including --path
getDefaultNamespace()	string	Returns empty string (migrations don't use namespaces)

Sources: src/Generator/NotificationTableCommand.php15-84

---

Comparison with Other Migration Commands

Unlike other database migration generators in this package, NotificationTableCommand has several unique characteristics:

Unique Characteristics

1. No Variable Substitution: Directly copies stub content without placeholder replacement
2. Single Table: Creates only one table (unlike cache system which creates two tables)
3. UUID Primary Key: Uses UUID instead of auto-incrementing bigint
4. Polymorphic Design: Built-in support for polymorphic relationships via morphs()

Related Commands

For complete database infrastructure setup, use in combination with:

• CacheTableCommand - Cache storage
• SessionTableCommand - Session storage
• QueueTableCommand - Job queue infrastructure

Sources: src/Generator/NotificationTableCommand.php1-84 src/Generator/stubs/notifications-table.stub1-32