feat(events): add database migrations for event management infrastructure#225
Open
GabrielFVDev wants to merge 4 commits into
Open
feat(events): add database migrations for event management infrastructure#225GabrielFVDev wants to merge 4 commits into
GabrielFVDev wants to merge 4 commits into
Conversation
… and networking features
…t check-ins, and referral clicks
…enrollments table
📝 WalkthroughWalkthroughThis PR introduces a comprehensive database schema rebuild for event management, centered on converting the events table from integer to UUID primary keys. It establishes a complete enrollment infrastructure with status tracking, check-in mechanisms (codes, QR tokens, verification), gamification through XP rewards, a referral system with click tracking, and networking features for attendee connections. An independent identity migration update makes schema alterations conditional on the PostgreSQL database driver, improving cross-database compatibility. Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (1)
app-modules/events/database/migrations/2026_05_13_225148_create_event_referral_clicks_table.php (1)
20-20: 💤 Low valueConsider using
created_atinstead of a separateclicked_atcolumn.The
timestamps()call on line 15 already creates acreated_atcolumn that captures when the click record is inserted. Having a separateclicked_atcolumn appears redundant unless:
- There's a processing delay between the actual click and record insertion
- You need to explicitly document the click time for business logic
If
clicked_atalways equalscreated_at, consider removing it to simplify the schema.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app-modules/events/database/migrations/2026_05_13_225148_create_event_referral_clicks_table.php` at line 20, The migration currently adds a redundant clicked_at column; remove the $table->timestamp('clicked_at') line in the create_event_referral_clicks_table migration and rely on the existing $table->timestamps() (created_at) to record the click time, or if you truly need an explicit click time different from insertion time, instead make clicked_at nullable and document in the migration why it differs from created_at; update the migration name create_event_referral_clicks_table and any related model/seed code to use created_at (or the nullable clicked_at) accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@app-modules/events/database/migrations/2026_05_13_224916_recreate_events_table_with_uuid.php`:
- Around line 13-67: The migration is destructive: it drops event_id FKs/columns
and the events table before preserving/mapping existing integer IDs to UUIDs,
which will lose relations; instead implement a non-destructive conversion: add a
nullable uuid column on events (e.g., uuid_id) and backfill it for each existing
row, add nullable shadow FK columns on dependents (events_talks.event_uuid_id,
events_attendees.event_uuid_id, events_sponsors.event_uuid_id,
events_agenda.event_uuid_id) and backfill them by joining on the old event_id,
then create UUID constraints/indexes (make events.id the uuid PK or swap PKs)
and update the dependent tables to use
foreignUuid('event_id')->constrained('events')->cascadeOnDelete(), finally drop
the old integer event_id columns and any temporary uuid_id/old id columns after
verification; search for Schema::table(...)->dropColumn('event_id'),
Schema::dropIfExists('events'), Schema::create('events'), and the
foreignUuid(...) calls to update the migration flow accordingly.
- Around line 13-31: Wrap the migration's foreign-key-modifying logic in calls
to Schema::disableForeignKeyConstraints() and
Schema::enableForeignKeyConstraints() so SQLite pragmas are handled correctly:
inside both the up() and down() methods, call
Schema::disableForeignKeyConstraints() before any Schema::table(...) operations
that drop foreign keys (e.g., events_talks/event_id, events_attendees/event_id,
events_sponsors/event_id, events_agenda/event_id) and call
Schema::enableForeignKeyConstraints() after those operations complete to restore
normal FK enforcement.
In
`@app-modules/events/database/migrations/2026_05_13_225144_create_event_enrollment_policies_table.php`:
- Line 29: The longitude column definition uses $table->decimal('venue_lng', 12,
10)->nullable() which cannot represent values up to ±180; update the migration
to use a precision/scale that allows three integer digits plus desired
fractional digits (for example $table->decimal('venue_lng', 11, 8)->nullable())
so valid longitudes are stored; modify the same pattern wherever venue_lng is
defined (and consider doing the same check for venue_lat if present).
In
`@app-modules/events/database/migrations/2026_05_13_225146_create_event_check_ins_table.php`:
- Line 20: The migration adds a unique constraint on enrollment_id (the line
$table->unique('enrollment_id')) which prevents multiple EventCheckIn records
per enrollment; remove that uniqueness or replace it with a non-unique index so
multiple check-ins can be recorded (or, if the intent is to keep only one
record, add a clarifying comment and enforce deduplication in application
logic). Locate the CreateEventCheckIns migration and remove or change
$table->unique('enrollment_id') to $table->index('enrollment_id') (or delete the
line) and, if needed, add a short comment explaining the chosen behavior for
EventCheckIn records.
In
`@app-modules/events/database/migrations/2026_05_13_225146_create_event_xp_rewards_table.php`:
- Around line 21-22: The migration creates polymorphic columns source_type and
source_id in the EventXpRewards table without referential integrity; add
safeguards by implementing application-level validation in the EventXpRewards
model/repository to verify the referenced record exists for the given
source_type/source_id before insert/update, add a documented contract in the
migration/class comment (create_event_xp_rewards_table / EventXpRewards)
describing the expected source types and lifecycle, and optionally add a DB
trigger or scheduled cleanup/monitoring job to detect and remediate orphaned
source_id entries and emit alerts when mismatches are found.
In
`@app-modules/events/database/migrations/2026_05_13_225147_create_networking_connections_table.php`:
- Around line 17-18: Add a CHECK constraint to the
create_networking_connections_table migration so a row cannot have the same
value for initiator_user_id and target_user_id; specifically, after defining the
foreignUuid columns (initiator_user_id and target_user_id) add a schema-level
CHECK (initiator_user_id <> target_user_id) constraint (or issue an ALTER TABLE
... ADD CONSTRAINT no_self_connection CHECK (...) via DB::statement) to block
self-connections.
- Around line 16-21: The migration currently only ensures initiator_user_id and
target_user_id exist in users, not that they are attendees of the event; update
the schema so each user reference is constrained together with event_id against
the attendees table (e.g. event_attendees or attendees). Replace the
single-column foreignUuid->constrained('users') for initiator_user_id and
target_user_id with composite foreign keys: (event_id, initiator_user_id)
references attendees(event_id, user_id) ON DELETE CASCADE and (event_id,
target_user_id) references attendees(event_id, user_id) ON DELETE CASCADE
(ensure the attendees table has a composite PK/unique on (event_id, user_id) to
allow this). Keep the event_id foreign key and the
unique(['event_id','initiator_user_id','target_user_id']) constraint.
---
Nitpick comments:
In
`@app-modules/events/database/migrations/2026_05_13_225148_create_event_referral_clicks_table.php`:
- Line 20: The migration currently adds a redundant clicked_at column; remove
the $table->timestamp('clicked_at') line in the
create_event_referral_clicks_table migration and rely on the existing
$table->timestamps() (created_at) to record the click time, or if you truly need
an explicit click time different from insertion time, instead make clicked_at
nullable and document in the migration why it differs from created_at; update
the migration name create_event_referral_clicks_table and any related model/seed
code to use created_at (or the nullable clicked_at) accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 93bd298c-e795-42ea-812b-33aaf97d5f42
📒 Files selected for processing (15)
app-modules/events/database/migrations/2026_05_13_224916_recreate_events_table_with_uuid.phpapp-modules/events/database/migrations/2026_05_13_225144_create_event_enrollment_policies_table.phpapp-modules/events/database/migrations/2026_05_13_225145_create_check_in_codes_table.phpapp-modules/events/database/migrations/2026_05_13_225145_create_event_enrollments_table.phpapp-modules/events/database/migrations/2026_05_13_225146_create_enrollment_transitions_table.phpapp-modules/events/database/migrations/2026_05_13_225146_create_event_check_ins_table.phpapp-modules/events/database/migrations/2026_05_13_225146_create_event_xp_rewards_table.phpapp-modules/events/database/migrations/2026_05_13_225146_create_magic_links_table.phpapp-modules/events/database/migrations/2026_05_13_225146_create_qr_tokens_table.phpapp-modules/events/database/migrations/2026_05_13_225147_create_event_referrals_table.phpapp-modules/events/database/migrations/2026_05_13_225147_create_networking_connections_table.phpapp-modules/events/database/migrations/2026_05_13_225147_create_networking_profiles_table.phpapp-modules/events/database/migrations/2026_05_13_225148_create_event_referral_clicks_table.phpapp-modules/events/database/migrations/2026_05_13_225149_add_referral_foreign_key_to_event_enrollments_table.phpapp-modules/identity/database/migrations/2026_04_19_000001_change_external_identities_metadata_to_jsonb.php
Comment on lines
+13
to
+67
| Schema::table('events_talks', function (Blueprint $table): void { | ||
| $table->dropForeign('events_talks_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::table('events_attendees', function (Blueprint $table): void { | ||
| $table->dropForeign('events_attendees_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::table('events_sponsors', function (Blueprint $table): void { | ||
| $table->dropForeign('events_sponsors_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::table('events_agenda', function (Blueprint $table): void { | ||
| $table->dropForeign('events_agenda_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::dropIfExists('events'); | ||
|
|
||
| Schema::create('events', function (Blueprint $table): void { | ||
| $table->uuid('id')->primary(); | ||
| $table->foreignId('tenant_id')->nullable()->constrained('tenants')->nullOnDelete(); | ||
| $table->string('event_type'); | ||
| $table->boolean('active')->default(true); | ||
| $table->string('slug')->unique(); | ||
| $table->string('title'); | ||
| $table->text('description'); | ||
| $table->timestamp('event_at'); | ||
| $table->timestamp('start_at'); | ||
| $table->timestamp('end_at'); | ||
| $table->string('location'); | ||
| $table->integer('max_attendees'); | ||
| $table->integer('attendees_count')->default(0); | ||
| $table->integer('waitlist_count')->default(0); | ||
| $table->timestamps(); | ||
| }); | ||
|
|
||
| Schema::table('events_talks', function (Blueprint $table): void { | ||
| $table->foreignUuid('event_id')->constrained('events')->cascadeOnDelete(); | ||
| }); | ||
|
|
||
| Schema::table('events_attendees', function (Blueprint $table): void { | ||
| $table->foreignUuid('event_id')->constrained('events')->cascadeOnDelete(); | ||
| }); | ||
|
|
||
| Schema::table('events_sponsors', function (Blueprint $table): void { | ||
| $table->foreignUuid('event_id')->constrained('events')->cascadeOnDelete(); | ||
| }); | ||
|
|
||
| Schema::table('events_agenda', function (Blueprint $table): void { | ||
| $table->foreignUuid('event_id')->constrained('events')->cascadeOnDelete(); | ||
| }); |
There was a problem hiding this comment.
Avoid destructive UUID conversion that drops existing event links.
Line 13 through Line 67 removes all existing event_id values and drops events before any ID mapping/backfill. This permanently loses relational data and can fail when adding back a non-null event_id to non-empty dependent tables.
Safer migration strategy (non-destructive)
- Add a new nullable UUID column to
events(e.g.,uuid_id) and backfill it for all existing rows. - Add nullable UUID shadow FKs on dependent tables (e.g.,
event_uuid_id) and backfill via join on old int IDs. - Switch constraints/indexes and PK/FKs to UUID after backfill is complete.
- Only then drop old int columns.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_224916_recreate_events_table_with_uuid.php`
around lines 13 - 67, The migration is destructive: it drops event_id
FKs/columns and the events table before preserving/mapping existing integer IDs
to UUIDs, which will lose relations; instead implement a non-destructive
conversion: add a nullable uuid column on events (e.g., uuid_id) and backfill it
for each existing row, add nullable shadow FK columns on dependents
(events_talks.event_uuid_id, events_attendees.event_uuid_id,
events_sponsors.event_uuid_id, events_agenda.event_uuid_id) and backfill them by
joining on the old event_id, then create UUID constraints/indexes (make
events.id the uuid PK or swap PKs) and update the dependent tables to use
foreignUuid('event_id')->constrained('events')->cascadeOnDelete(), finally drop
the old integer event_id columns and any temporary uuid_id/old id columns after
verification; search for Schema::table(...)->dropColumn('event_id'),
Schema::dropIfExists('events'), Schema::create('events'), and the
foreignUuid(...) calls to update the migration flow accordingly.
Comment on lines
+13
to
+31
| Schema::table('events_talks', function (Blueprint $table): void { | ||
| $table->dropForeign('events_talks_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::table('events_attendees', function (Blueprint $table): void { | ||
| $table->dropForeign('events_attendees_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::table('events_sponsors', function (Blueprint $table): void { | ||
| $table->dropForeign('events_sponsors_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); | ||
|
|
||
| Schema::table('events_agenda', function (Blueprint $table): void { | ||
| $table->dropForeign('events_agenda_event_id_foreign'); | ||
| $table->dropColumn('event_id'); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
find . -type f -name "*recreate_events_table_with_uuid*" 2>/dev/nullRepository: he4rt/heartdevs.com
Length of output: 158
🏁 Script executed:
cat -n ./app-modules/events/database/migrations/2026_05_13_224916_recreate_events_table_with_uuid.phpRepository: he4rt/heartdevs.com
Length of output: 5909
🏁 Script executed:
find . -type f -name "database.php" -o -name "*.php" -path "*/config/*" | grep -E "(database|config)" | head -20Repository: he4rt/heartdevs.com
Length of output: 695
🏁 Script executed:
cat -n ./config/database.phpRepository: he4rt/heartdevs.com
Length of output: 8354
Use disableForeignKeyConstraints() to handle SQLite FK operations safely.
This migration manually drops foreign keys before altering the parent events table, which technically works on SQLite. However, it bypasses Laravel's built-in Schema::disableForeignKeyConstraints()/enableForeignKeyConstraints() wrapper, which properly manages database-specific foreign key pragmas. Wrapping the entire migration logic (both up() and down() methods) with these methods would be more robust and maintainable, especially since the project uses SQLite as the default database with foreign_key_constraints enabled by default.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_224916_recreate_events_table_with_uuid.php`
around lines 13 - 31, Wrap the migration's foreign-key-modifying logic in calls
to Schema::disableForeignKeyConstraints() and
Schema::enableForeignKeyConstraints() so SQLite pragmas are handled correctly:
inside both the up() and down() methods, call
Schema::disableForeignKeyConstraints() before any Schema::table(...) operations
that drop foreign keys (e.g., events_talks/event_id, events_attendees/event_id,
events_sponsors/event_id, events_agenda/event_id) and call
Schema::enableForeignKeyConstraints() after those operations complete to restore
normal FK enforcement.
| $table->integer('xp_reward_checkin')->default(0); | ||
| $table->integer('xp_reward_referral')->default(0); | ||
| $table->decimal('venue_lat', 11, 7)->nullable(); | ||
| $table->decimal('venue_lng', 12, 10)->nullable(); |
There was a problem hiding this comment.
Fix longitude precision/scale to support full valid range.
Line 29 uses decimal(12, 10), which only supports up to ±99.9999999999. Valid longitude needs up to ±180, so many real locations cannot be stored.
Suggested fix
- $table->decimal('venue_lng', 12, 10)->nullable();
+ $table->decimal('venue_lng', 13, 10)->nullable();📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| $table->decimal('venue_lng', 12, 10)->nullable(); | |
| $table->decimal('venue_lng', 13, 10)->nullable(); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_225144_create_event_enrollment_policies_table.php`
at line 29, The longitude column definition uses $table->decimal('venue_lng',
12, 10)->nullable() which cannot represent values up to ±180; update the
migration to use a precision/scale that allows three integer digits plus desired
fractional digits (for example $table->decimal('venue_lng', 11, 8)->nullable())
so valid longitudes are stored; modify the same pattern wherever venue_lng is
defined (and consider doing the same check for venue_lat if present).
| $table->string('method'); | ||
| $table->jsonb('payload')->nullable(); | ||
| $table->foreignUuid('verified_by_user_id')->nullable()->constrained('users')->nullOnDelete(); | ||
| $table->unique('enrollment_id'); |
There was a problem hiding this comment.
Unique constraint on enrollment_id prevents multiple check-in records.
The unique constraint means each enrollment can have only one check-in record. This design prevents tracking:
- Multiple check-in attempts (for retry scenarios)
- Re-entries if the event spans multiple days
- Failed verification attempts followed by successful ones
If the business requirement truly enforces "one check-in per enrollment ever," this is correct. However, most event systems track all check-in attempts for audit and analytics.
Consider removing this constraint to allow multiple check-in records per enrollment, or clarify in a comment that only the most recent/valid check-in is stored.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_225146_create_event_check_ins_table.php`
at line 20, The migration adds a unique constraint on enrollment_id (the line
$table->unique('enrollment_id')) which prevents multiple EventCheckIn records
per enrollment; remove that uniqueness or replace it with a non-unique index so
multiple check-ins can be recorded (or, if the intent is to keep only one
record, add a clarifying comment and enforce deduplication in application
logic). Locate the CreateEventCheckIns migration and remove or change
$table->unique('enrollment_id') to $table->index('enrollment_id') (or delete the
line) and, if needed, add a short comment explaining the chosen behavior for
EventCheckIn records.
Comment on lines
+21
to
+22
| $table->string('source_type'); | ||
| $table->uuid('source_id'); |
There was a problem hiding this comment.
Polymorphic relationship without referential integrity.
The source_type/source_id columns implement a polymorphic relationship pattern, but source_id has no foreign key constraint. This creates a data integrity risk:
source_idcan reference deleted records- No database-level enforcement prevents orphaned references
- Application code must manually maintain consistency
While polymorphic foreign keys are not directly supported in SQL, consider:
- Adding application-level validation to ensure source_id references exist before insert/update
- Adding database triggers if supported
- Documenting this constraint clearly
- Implementing regular cleanup jobs to detect/fix orphaned references
Consider adding monitoring/alerts for orphaned source_id references to catch data integrity violations early.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_225146_create_event_xp_rewards_table.php`
around lines 21 - 22, The migration creates polymorphic columns source_type and
source_id in the EventXpRewards table without referential integrity; add
safeguards by implementing application-level validation in the EventXpRewards
model/repository to verify the referenced record exists for the given
source_type/source_id before insert/update, add a documented contract in the
migration/class comment (create_event_xp_rewards_table / EventXpRewards)
describing the expected source types and lifecycle, and optionally add a DB
trigger or scheduled cleanup/monitoring job to detect and remediate orphaned
source_id entries and emit alerts when mismatches are found.
Comment on lines
+16
to
+21
| $table->foreignUuid('event_id')->constrained('events')->cascadeOnDelete(); | ||
| $table->foreignUuid('initiator_user_id')->constrained('users')->cascadeOnDelete(); | ||
| $table->foreignUuid('target_user_id')->constrained('users')->cascadeOnDelete(); | ||
| $table->string('status'); | ||
| $table->text('message')->nullable(); | ||
| $table->unique(['event_id', 'initiator_user_id', 'target_user_id']); |
There was a problem hiding this comment.
Enforce attendee membership at the DB level for both users.
Right now, Line 17 and Line 18 only ensure the users exist, not that they are enrolled attendees of Line 16’s event. This allows invalid cross-event/non-attendee connections.
Suggested migration direction
Schema::create('networking_connections', function (Blueprint $table): void {
$table->uuid('id')->primary();
$table->timestamps();
$table->foreignUuid('event_id')->constrained('events')->cascadeOnDelete();
$table->foreignUuid('initiator_user_id')->constrained('users')->cascadeOnDelete();
$table->foreignUuid('target_user_id')->constrained('users')->cascadeOnDelete();
$table->string('status');
$table->text('message')->nullable();
$table->unique(['event_id', 'initiator_user_id', 'target_user_id']);
+
+ // enforce both users are attendees of this event
+ $table->foreign(['event_id', 'initiator_user_id'])
+ ->references(['event_id', 'user_id'])
+ ->on('event_enrollments')
+ ->cascadeOnDelete();
+
+ $table->foreign(['event_id', 'target_user_id'])
+ ->references(['event_id', 'user_id'])
+ ->on('event_enrollments')
+ ->cascadeOnDelete();
});🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_225147_create_networking_connections_table.php`
around lines 16 - 21, The migration currently only ensures initiator_user_id and
target_user_id exist in users, not that they are attendees of the event; update
the schema so each user reference is constrained together with event_id against
the attendees table (e.g. event_attendees or attendees). Replace the
single-column foreignUuid->constrained('users') for initiator_user_id and
target_user_id with composite foreign keys: (event_id, initiator_user_id)
references attendees(event_id, user_id) ON DELETE CASCADE and (event_id,
target_user_id) references attendees(event_id, user_id) ON DELETE CASCADE
(ensure the attendees table has a composite PK/unique on (event_id, user_id) to
allow this). Keep the event_id foreign key and the
unique(['event_id','initiator_user_id','target_user_id']) constraint.
Comment on lines
+17
to
+18
| $table->foreignUuid('initiator_user_id')->constrained('users')->cascadeOnDelete(); | ||
| $table->foreignUuid('target_user_id')->constrained('users')->cascadeOnDelete(); |
There was a problem hiding this comment.
Block self-connections with a check constraint.
Line 17 and Line 18 currently allow a user to connect to themselves, which is usually invalid for networking flows.
Suggested constraint
Schema::create('networking_connections', function (Blueprint $table): void {
@@
$table->foreignUuid('initiator_user_id')->constrained('users')->cascadeOnDelete();
$table->foreignUuid('target_user_id')->constrained('users')->cascadeOnDelete();
@@
+ $table->check('initiator_user_id <> target_user_id');
});🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@app-modules/events/database/migrations/2026_05_13_225147_create_networking_connections_table.php`
around lines 17 - 18, Add a CHECK constraint to the
create_networking_connections_table migration so a row cannot have the same
value for initiator_user_id and target_user_id; specifically, after defining the
foreignUuid columns (initiator_user_id and target_user_id) add a schema-level
CHECK (initiator_user_id <> target_user_id) constraint (or issue an ALTER TABLE
... ADD CONSTRAINT no_self_connection CHECK (...) via DB::statement) to block
self-connections.
Contributor
|
LGTM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O módulo de events já tinha a tabela
eventsbase, mas sem suporte a inscrições gerenciadas, check-in, referrals ou networking. Esta PRadiciona toda a estrutura de banco necessária para o fluxo completo de gestão de eventos, migrando também a tabela
eventspara UUIDcomo chave primária.
O que foi implementado
Migração da tabela
eventspara UUIDA tabela foi recriada com
iddo tipo UUID. As relações existentes (events_talks,events_attendees,events_sponsors,events_agenda) tiveram suas FKs derrubadas e recriadas apontando para UUID.Inscrições
event_enrollment_policiesevent_enrollmentsenrollment_transitionsCheck-in
check_in_codesevent_check_insqr_tokensmagic_linksReferrals
event_referralsevent_referral_clicksXP e recompensas
event_xp_rewards(enrollment_id, reason)Networking
networking_profilesnetworking_connectionsFix na migration de
external_identitiesA conversão de
metadatadejsonparajsonbagora é condicional ao driverpgsql, evitando falha em ambientes com SQLite.Arquivos alterados
Migrations em
app-modules/events/database/migrations/salvo onde indicado.recreate_events_table_with_uuid.phpcreate_event_enrollment_policies_table.phpcreate_event_enrollments_table.phpcreate_check_in_codes_table.phpcreate_enrollment_transitions_table.phpcreate_event_check_ins_table.phpcreate_event_xp_rewards_table.phpcreate_magic_links_table.phpcreate_qr_tokens_table.phpcreate_event_referrals_table.phpcreate_networking_connections_table.phpcreate_networking_profiles_table.phpcreate_event_referral_clicks_table.phpadd_referral_foreign_key_to_event_enrollments_table.phpidentity/…/change_external_identities_metadata_to_jsonb.phpComo testar
php artisan migrate:freshe confirme que todas as migrations executam sem erroevents.idé do tipo UUID no bancoevents_talks, etc.) apontando para UUIDevent_enrollments.referral_id → event_referrals.idphp artisan migrate:fresh --env=testingpara garantir que não quebra em SQLiteDescription
This PR introduces comprehensive database migration infrastructure for event management, converting the
eventstable primary key to UUID and adding 13 new tables to support event enrollments, check-ins, referrals, XP rewards, and networking features. Additionally, a migration in the identity module conditionally convertsexternal_identities.metadatato JSONB for PostgreSQL compatibility.References
Related prior work:
Dependencies & Requirements
No new external dependencies added. No environment variables or configuration updates required. The migrations are compatible with both PostgreSQL and SQLite (conditional JSONB conversion for PostgreSQL).
Contributor Summary
Changes Summary
events.idto UUID primary key, recreates table with full schema, re-establishes foreign keys to dependent tablesevent_enrollments.referral_idtoevent_referrals.idwith null-on-deleteexternal_identities.metadatacolumn from JSON to JSONB for PostgreSQL only