Eventify ships with a complete seeding pipeline that turns a blank database into a fully working local environment in seconds. A single Artisan command wipes and recreates every table, runs all migrations, and then sequences through four dedicated seeders before generating realistic sample content with Eloquent factories. The result is a database that contains two roles, six event categories, three availability statuses, a ready-to-use admin account, and thirty sample events — everything you need to explore the application without any manual data entry.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/astrxnomo/eventify-app/llms.txt
Use this file to discover all available pages before exploring further.
Running the seeders
The fastest way to get a clean, fully seeded database is:DatabaseSeeder. If your schema is already up to date and you only want to re-seed without re-running migrations, use:
Re-running
db:seed on a database that already contains data may cause duplicate-entry errors for seeders that do not use firstOrCreate. It is safer to always use migrate:fresh --seed during development.Seeder execution order
DatabaseSeeder calls each seeder and factory in a strict sequence to respect foreign key dependencies.
RolesTableSeeder
Creates the
Administrator and User roles. Must run first because users.role_id is a foreign key into roles.CategoryTableSeeder
Inserts the six built-in event categories. Must exist before events are generated by the factory.
StatusTableSeeder
Inserts the three availability statuses. Must exist before events are generated, since
events.status_id defaults to 1.UserTableSeeder
Creates the default admin account. The admin user must exist before the EventFactory can assign
user_id values to events.User::factory()->count(5)->create()
Generates five additional random users via Faker so the EventFactory has a pool of users to assign as event organisers.
Location::factory()->count(30)->create()
Generates thirty random venue records. The EventFactory assigns locations sequentially, so locations must be created first.
DatabaseSeeder::run() method looks like this:
RolesTableSeeder
RolesTableSeeder uses firstOrCreate to insert the two application roles, making it safe to run more than once without creating duplicates.
id | name | label | description |
|---|---|---|---|
1 | Administrator | admin | System Administrator |
2 | User | user | Regular User |
users.role_id column defaults to 2, so every account created without an explicit role is automatically assigned the User role.
CategoryTableSeeder
CategoryTableSeeder inserts six categories that cover the primary event types offered on the platform.
id | name |
|---|---|
1 | Musical |
2 | Teatro |
3 | Deportivo |
4 | Cultural |
5 | Familiar |
6 | Gastronómico |
StatusTableSeeder
StatusTableSeeder inserts three statuses that reflect the availability lifecycle of an event.
id | name | Meaning |
|---|---|---|
1 | Disponible | Tickets are available for purchase. |
2 | Agotado | The event is sold out; no tickets remain. |
3 | Finalizado | The event has concluded. |
events.status_id defaults to 1, every newly created event starts as Disponible unless a different value is specified explicitly.
UserTableSeeder
UserTableSeeder creates a single default admin account that is ready to use immediately after seeding.
| Field | Value |
|---|---|
| Name | Admin |
admin@admin.com | |
| Password | 123456789 |
| Role | Administrator (1) |
Factories
After the explicit seeders run,DatabaseSeeder uses three Eloquent factories to generate bulk sample data.
UserFactory
Generates five random users. Each factory-created user receives a Faker-generated name, a unique safe email address, a verified timestamp, and the same hashed default password (123456789). No explicit role_id is set, so each user inherits the column default of 2 (User role).
LocationFactory
Generates thirty venue records using Faker’s address helpers. Latitude and longitude are populated with full decimal-degree precision, giving every sample event a realistic map-ready location.EventFactory
Generates thirty events. Locations are assigned sequentially (starting fromid = 1) so that each event receives a unique venue. The organising user and category are each picked at random from the existing records. Event images are downloaded from picsum.photos and stored in the public disk under events/.
The EventFactory makes live HTTP requests to
picsum.photos to fetch cover images during seeding. Ensure your development machine has outbound internet access before running migrate:fresh --seed, or the factory will throw a connection error.