Files that changed from the base of the PR and between 18dacda and 3da1278.

• libs/db/src/index.ts (1 hunks)
• libs/db/src/schema/emergencyContact.ts (1 hunks)
• libs/db/src/schema/index.ts (1 hunks)
• libs/db/src/schema/program.ts (1 hunks)
• libs/db/src/schema/resume.ts (1 hunks)
• libs/db/src/schema/school.ts (1 hunks)
• libs/db/src/schema/session.ts (1 hunks)
• libs/db/src/schema/socialMedia.ts (1 hunks)
• libs/db/src/schema/team.ts (1 hunks)
• libs/db/src/schema/user.ts (1 hunks)
• libs/db/src/schema/userPreferences.ts (1 hunks)

libs/db/src/schema/index.ts (1)

1-9: LGTM! Consider organizing exports alphabetically.

The new exports align well with the PR objective of creating initial portal database schemas for user profiles. The inclusion of various aspects like emergency contacts, programs, resumes, etc., provides a comprehensive structure for user data.

To improve readability and maintainability, consider organizing the exports alphabetically. This would make it easier to locate specific modules in the future, especially as the number of exports grows.

Here's a suggested reorganization:

export * from './emergencyContact'
export * from './program'
export * from './resume'
export * from './school'
export * from './session'
export * from './socialMedia'
export * from './team'
export * from './user'
export * from './userPreferences'

Let's verify the existence of the newly exported modules:

This script will help ensure that all the exported schema modules have corresponding files in the expected location.

✅ Verification successful

All exported schema modules verified successfully.

All the exported schema modules have been confirmed to exist as expected.

To improve readability and maintainability, consider organizing the exports alphabetically.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of the newly exported schema modules

# Test: Check if all the exported schema files exist
for schema in emergencyContact program resume school session socialMedia team user userPreferences; do
  if [ ! -f "libs/db/src/schema/${schema}.ts" ]; then
    echo "Error: ${schema}.ts does not exist"
    exit 1
  fi
done

echo "All schema files exist"

Length of output: 1399

libs/db/src/schema/session.ts (2)

Line range hint 10-14: Approve the renaming of expires_at to expiresAt and request clarification on timestamp mode.

The change to camelCase is consistent with JavaScript conventions and the previous field change. The use of a timestamp with timezone is appropriate for session expiration.

Please run the following script to check for any remaining references to expires_at:

#!/bin/bash
# Search for any remaining references to 'expires_at' in TypeScript files
rg --type typescript 'expires_at' -g '!libs/db/src/schema/session.ts'

Could you please clarify the purpose of setting mode: 'date' for the timestamp? It's not immediately clear what this setting does in the context of Drizzle ORM and how it affects the stored expiration time.

---

7-9: Approve the renaming of user_id to userId.

The change from snake_case to camelCase improves consistency with JavaScript naming conventions while maintaining the field's properties and relationships.

To ensure this change doesn't break existing code, please run the following script to check for any remaining references to user_id:

✅ Verification successful

Verified the renaming of user_id to userId.

The remaining references to 'user_id' in drizzle/schema.ts are part of the schema definitions and correctly map the ORM field userId to the database column user_id. This change maintains consistency in the codebase without introducing issues.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining references to 'user_id' in TypeScript files
rg --type typescript 'user_id' -g '!libs/db/src/schema/session.ts'

Length of output: 104

---

Script:

#!/bin/bash
# Search for any remaining references to 'user_id' in TypeScript files
rg --type ts 'user_id' -g '!libs/db/src/schema/session.ts'

Length of output: 173

libs/db/src/schema/resume.ts (1)

1-1: LGTM: Imports are appropriate and fully utilized.

The imports from 'drizzle-orm/pg-core' are correct and all imported types (boolean, pgTable, serial, timestamp, varchar) are used in the schema definition.

libs/db/src/schema/school.ts (2)

1-1: LGTM: Imports are correct and necessary.

The imports from 'drizzle-orm/pg-core' are appropriate for defining PostgreSQL tables and enums using Drizzle ORM.

---

1-9: Overall implementation aligns well with PR objectives.

This schema definition for the 'school' table is a solid starting point for the portal database. It successfully uses Drizzle ORM, aligning with the PR objectives of leveraging an ORM for type safety and efficient migrations. The basic structure is in place, allowing for easy expansion as requirements evolve.

Consider the suggestions for expanding the level of study enum and adding more fields to the school table to make the schema more comprehensive. These changes can be implemented now or in future iterations, depending on your immediate needs and timeline.

Remember that this is part of the initial schema setup, and as mentioned in the PR description, further updates and refinements are anticipated. The current implementation provides a good foundation for these future changes.

libs/db/src/schema/socialMedia.ts (1)

1-1: LGTM: Appropriate imports for Drizzle ORM schema definition.

The imports from 'drizzle-orm/pg-core' are correct and all imported items are utilized in the schema definition.

libs/db/src/schema/program.ts (2)

1-2: LGTM: Imports are appropriate for the schema definition.

The imports from 'drizzle-orm/pg-core' provide the necessary tools for defining the PostgreSQL table schema. The import of 'school' indicates a relationship between the 'program' and 'school' tables, which aligns with the expected database structure.

---

1-11: Overall: Well-structured schema implementation for the 'program' table.

This file successfully implements the initial schema for the 'program' table using Drizzle ORM, aligning with the PR objectives. The structure is clear, establishes necessary relationships, and provides a solid foundation for the portal database.

Key points:

1. Appropriate use of Drizzle ORM for type-safe schema definition.
2. Clear enum definition for program types.
3. Well-structured table with primary key, foreign key relationship, and use of custom enum.

The implementation serves as a good starting point for the portal database schemas. As mentioned in the PR description, this is a temporary draft and subject to change, which allows for future refinements based on evolving requirements.

To ensure consistency with other parts of the schema, let's verify the 'school' table structure:

This will help confirm that the 'school' table exists and has a compatible structure for the foreign key relationship.

libs/db/src/schema/team.ts (3)

1-1: LGTM: Imports are appropriate and concise.

The imports from 'drizzle-orm/pg-core' are correctly selected for defining a PostgreSQL table schema. All imported types are utilized in the schema definition, maintaining a clean and efficient import statement.

---

1-13: Overall, good initial implementation of the team schema.

This file successfully introduces the 'team' table schema using Drizzle ORM, aligning with the PR objectives. The implementation provides a solid foundation for the portal database, allowing for easy future refinements as mentioned in the PR description.

Key points:

1. The schema covers essential team attributes.
2. Use of Drizzle ORM facilitates type safety and efficient migrations.
3. The structure allows for future updates, such as merging with a potential UserPreferences table.

Consider the suggested improvements in the previous comment to enhance data integrity and reduce redundancy. As this is described as a temporary, rough draft, these changes can be incorporated in future iterations of the schema.

---

3-13: 🛠️ Refactor suggestion

Consider additional constraints and potential redundancy in the schema.

The schema is well-structured, but consider the following improvements:

1. Add a 'not null' constraint to the 'name' field, as every team should have a name.
2. There seems to be redundancy between 'profileImageUrl' and 'teamProfileImageUrl'. Consider consolidating these into a single field.
3. If there's a corresponding 'user' table, add a foreign key constraint to 'teamOwnerId'.
4. Consider adding unique constraints where appropriate (e.g., 'name' field).

Here's a suggested revision:

export const team = pgTable('team', {
  id: serial('id').primaryKey(),
  name: varchar('name', { length: 64 }).notNull().unique(),
  profileImageUrl: varchar('profileImageUrl', { length: 128 }),
  projectLinkUrl: varchar('projectLinkUrl', { length: 256 }),
  teamOwnerId: integer('teamOwnerId').references(() => user.id), // Assuming a 'user' table exists
  hasSubmitted: boolean('hasSubmitted').default(false),
});

This revision addresses the mentioned points and aligns with the PR objectives of establishing an initial, changeable schema.

To verify the existence of a 'user' table and its structure, run:

✅ Verification successful

Verification Successful: Foreign key constraint is valid.

The 'user' table exists with an 'id' field defined as a primary key, confirming that adding a foreign key constraint to 'teamOwnerId' is appropriate.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for 'user' table definition
# Expected result: A 'user' table definition with an 'id' field

rg --type typescript 'export const user = pgTable\(' libs/db/src/schema

Length of output: 108

---

Script:

#!/bin/bash
# Description: Check for 'user' table definition using the correct type identifier
# Expected result: A 'user' table definition with an 'id' field

rg --type ts 'export const user = pgTable\(' libs/db/src/schema

Length of output: 130

---

Script:

#!/bin/bash
# Description: Verify the 'id' field in the 'user' table definition
# Expected result: The 'id' field is defined as a primary key

rg "id\s*:\s*serial\('id'\)\.primaryKey\(\)" libs/db/src/schema/user.ts

Length of output: 112

libs/db/src/schema/emergencyContact.ts (1)

1-1: LGTM: Imports are appropriate and used correctly.

The necessary functions from 'drizzle-orm/pg-core' are imported for defining the PostgreSQL table schema using Drizzle ORM.

libs/db/src/schema/userPreferences.ts (2)

17-17: Ensure default value for preferredLanguage accommodates all users.

While 'EN' is set as the default, consider if this is appropriate for your user base. If the application supports multiple languages, users might prefer to set their language during registration.

---

23-27: Verify handling of empty arrays for preference fields.

Ensure that the application and database correctly handle scenarios where users have not selected any options for dietRestrictions, trackPreferences, interests, disabilities, and applicableSkills. This might involve setting default empty arrays or allowing null values.

Consider adding default empty arrays:

- dietRestrictions: dietRestrictionsEnum('dietRestrictions').array(),
+ dietRestrictions: dietRestrictionsEnum('dietRestrictions').array().default([]),

Apply similar changes to the other array fields if appropriate.

libs/db/src/schema/user.ts (3)

32-35: Ensure foreign key constraints are correctly enforced

The foreign keys resumeId, schoolId, emergencyContactId, and teamId may require .notNull() if these relationships are mandatory.

Please verify if these associations are optional. If they are required, consider:

-resumeId: integer('resumeId').references(() => resume.id),
+resumeId: integer('resumeId').references(() => resume.id).notNull(),

Repeat for the other foreign keys as needed.

---

21-21: Handle dateOfBirth with care for compliance

Collecting dateOfBirth may have implications under data protection regulations like GDPR or COPPA, especially for users under certain ages.

Ensure that:

• Appropriate consent is obtained.
• Data is stored and processed in compliance with regulations.
• Age-related access controls are implemented if necessary.

---

26-26: Check the datatype for numHackathonsAttended

Using smallint limits the maximum value to 32,767. If users might attend more hackathons, or if this field could be misused, consider using a larger integer type.

Files that changed from the base of the PR and between 3da1278 and b4dfeae.

• apps/docs/next.config.mjs (1 hunks)

Files that changed from the base of the PR and between 417207a and 3889133.

• apps/docs/src/content/docs/libraries/db.mdx (3 hunks)

apps/docs/src/content/docs/libraries/db.mdx (2)

176-179: Improved clarity in Drizzle-Kit commands section

The changes in this section enhance the documentation by providing more specific information about Drizzle-Kit commands and including an example of how to run a migration. This improvement in clarity will be helpful for developers using the library.

---

229-229: Helpful addition of troubleshooting resource

The inclusion of a link to DrizzleORM's troubleshooting page is a valuable addition to the documentation. It provides users with an official resource for resolving issues they may encounter while working with DrizzleORM.

Files that changed from the base of the PR and between 3889133 and 33a5186.

• apps/docs/next.config.mjs (2 hunks)
• apps/docs/src/content/docs/knowledge-base/cuHacking-2020-wiki/meta.json (0 hunks)
• apps/docs/src/content/docs/libraries/db.mdx (3 hunks)

• apps/docs/src/content/docs/knowledge-base/cuHacking-2020-wiki/meta.json

apps/docs/next.config.mjs (1)

1-1: LGTM: Explicit import of process module.

The explicit import of the process module is correct and follows best practices for Next.js configurations, especially in newer versions where Node.js APIs might need to be imported explicitly.

apps/docs/src/content/docs/libraries/db.mdx (2)

176-177: Improved clarity and added helpful link.

The text adjustments enhance readability and provide more comprehensive information about available Drizzle-Kit commands. The addition of the link to the official documentation is particularly useful for users who need more detailed information.

---

229-229: Helpful addition of troubleshooting resource.

The inclusion of a link to DrizzleORM's official troubleshooting page is a valuable addition. It provides users with an authoritative source for resolving issues they might encounter while working with the library.

Files that changed from the base of the PR and between 33a5186 and 4dc2a04.

• apps/docs/next.config.mjs (2 hunks)
• apps/docs/src/content/docs/knowledge-base/cuHacking-2020-wiki/meta.json (0 hunks)
• apps/docs/src/content/docs/libraries/db.mdx (3 hunks)
• libs/db/src/index.ts (1 hunks)
• libs/db/src/schema/emergencyContact.ts (1 hunks)
• libs/db/src/schema/index.ts (1 hunks)
• libs/db/src/schema/program.ts (1 hunks)
• libs/db/src/schema/resume.ts (1 hunks)
• libs/db/src/schema/school.ts (1 hunks)
• libs/db/src/schema/session.ts (1 hunks)
• libs/db/src/schema/socialMedia.ts (1 hunks)
• libs/db/src/schema/team.ts (1 hunks)
• libs/db/src/schema/user.ts (1 hunks)
• libs/db/src/schema/userPreferences.ts (1 hunks)

• apps/docs/src/content/docs/knowledge-base/cuHacking-2020-wiki/meta.json

• apps/docs/next.config.mjs
• apps/docs/src/content/docs/libraries/db.mdx
• libs/db/src/index.ts
• libs/db/src/schema/emergencyContact.ts
• libs/db/src/schema/index.ts
• libs/db/src/schema/program.ts
• libs/db/src/schema/resume.ts
• libs/db/src/schema/school.ts
• libs/db/src/schema/session.ts
• libs/db/src/schema/socialMedia.ts
• libs/db/src/schema/team.ts

libs/db/src/schema/userPreferences.ts (9)

1-2: Imports look good!

The necessary functions from 'drizzle-orm/pg-core' are imported, and the 'user' import suggests proper modularization of the schema.

---

1-28: Overall assessment: Good foundation with room for improvement

The userPreferences schema provides a solid foundation for storing user preferences. The suggested improvements will enhance the schema's inclusivity, flexibility, and data integrity. Key areas for improvement include:

1. Expanding enum options to be more inclusive and comprehensive.
2. Adding referential integrity constraints to the foreign key.
3. Considering array types for multi-select preferences.
4. Adding timestamps for better record tracking.
5. Implementing a unique constraint on userId.

These changes will result in a more robust and user-friendly schema. Great work on setting up this initial structure!

---

28-28: 🛠️ Refactor suggestion

Add timestamps for record tracking.

Including createdAt and updatedAt timestamps can be beneficial for tracking when records are created and modified.

   applicableSkills: applicableSkillsEnum('applicableSkills').array(),
+  createdAt: timestamp('createdAt').defaultNow(),
+  updatedAt: timestamp('updatedAt').defaultNow().onUpdateNow(),
 })

Don't forget to import timestamp at the top of the file:

-import { boolean, integer, pgEnum, pgTable, serial } from 'drizzle-orm/pg-core'
+import { boolean, integer, pgEnum, pgTable, serial, timestamp } from 'drizzle-orm/pg-core'

Likely invalid or redundant comment.

---

16-16: 🛠️ Refactor suggestion

Specify onDelete and onUpdate actions for the foreign key userId.

To maintain referential integrity, it's important to define what happens to userPreferences entries when a referenced user is deleted or updated.

-  userId: integer('userId').references(() => user.id),
+  userId: integer('userId').references(() => user.id, { onDelete: 'cascade', onUpdate: 'cascade' }),

Likely invalid or redundant comment.

---

7-7: 🛠️ Refactor suggestion

Add a 'Prefer not to say' option to pronounsEnum.

Including a 'Prefer not to say' option allows users who do not wish to disclose their pronouns to have an appropriate selection.

-export const pronounsEnum = pgEnum('pronouns', ['he/him', 'she/her', 'they/them', 'other'])
+export const pronounsEnum = pgEnum('pronouns', ['he/him', 'she/her', 'they/them', 'other', 'prefer not to say'])

Likely invalid or redundant comment.

---

18-18: 🛠️ Refactor suggestion

Consider allowing multiple selections for eventPreferences.

If users can select multiple event preferences, you should define eventPreferences as an array type.

-  eventPreferences: eventPreferencesEnum('eventPreferences'),
+  eventPreferences: eventPreferencesEnum('eventPreferences').array(),

Likely invalid or redundant comment.

---

11-11: 🛠️ Refactor suggestion

Consider adding 'Other' to disabilitiesEnum.

Including an 'Other' option allows users with disabilities not listed to accurately represent their needs.

-export const disabilitiesEnum = pgEnum('disabilities', ['mobility', 'visual', 'hearing', 'cognitive', 'mental'])
+export const disabilitiesEnum = pgEnum('disabilities', ['mobility', 'visual', 'hearing', 'cognitive', 'mental', 'other'])

Likely invalid or redundant comment.

---

8-8: 🛠️ Refactor suggestion

Expand dietRestrictionsEnum to include more dietary options.

To accommodate a wider range of dietary needs, consider adding more options.

-export const dietRestrictionsEnum = pgEnum('dietRestrictions', ['allergies', 'vegan', 'none'])
+export const dietRestrictionsEnum = pgEnum('dietRestrictions', ['allergies', 'vegan', 'vegetarian', 'gluten-free', 'halal', 'kosher', 'nut-free', 'none', 'other'])

Likely invalid or redundant comment.

---

9-9: 🛠️ Refactor suggestion

Broaden the options in trackPreferencesEnum.

If the event offers additional tracks, consider expanding this enum to provide users with more accurate preference options.

-export const trackPreferencesEnum = pgEnum('trackPreferences', ['hardware', 'software'])
+export const trackPreferencesEnum = pgEnum('trackPreferences', ['hardware', 'software', 'design', 'data_science', 'cybersecurity', 'other'])

Likely invalid or redundant comment.

libs/db/src/schema/user.ts (1)

1-5: LGTM: Imports are appropriate and used correctly

The imports from 'drizzle-orm/pg-core' and other schema files are correctly utilized in the schema definition, providing necessary types and references for foreign keys.