Home
Github
Wiki
Videos
Contact
Sponsor
Working with a Custom Database Schema and Identity User
while you can use the Puck apis to add content to your website, at some point, you'll likely want to have database tables for your site specific custom data and working with `Identity` you'll likely want your own `User` with custom fields. puck sets this up for you in the `puckweb` project, in the `Data` folder. you'll notice in the `Data/Contexts` folder there are five `DbContext`s, one for each database supported by `Puck` and the fifth is the `ApplicationDbContext` which is the `DbContext` you add your custom tables/entities to. Entities go in the `Data/Entities` folder, you'll find `User` is in that folder and this is the `IdentityUser` you can edit with custom fields. **custom fields in `User` must be nullable** - this is because the same `AspNetUsers` table is used for your site `User` and the backoffice `PuckUser` so if you add properties that are not nullable, when users are retrieved in the backoffice there will be errors because those non-nullable properties will not have values. you add your custom data to the `ApplicationDbContext` and you add migrations using your database-specific context. so if in the `appSettings.json` you've set `UseSQLServer`, an example migration command in the package manager console will look like `add-migration blog -context DbContextSQLServer`. you will also need to specify which context to use when issuing an `update-database` command - again, use the database specific context, `update-database -context DbContextSQLServer`. also, make sure the default project is set to `puckweb` in the package manager console when issuing these commands. you can then inject the database specific context (`DbContextSQLServer` or `DbContextMySQL` or `DbContextPostgreSQL` or `DbContextSQLite`) into your controllers. ## table and property name collisions since by default your site and the `Puck` backoffice will be sharing a database, it's important that you avoid naming collisions in your custom tables and in the properties you add to your custom `User`. all `Puck` tables are prefixed with "Puck" and all `PuckUser` properties are also prefixed with "Puck" so as long as you avoid naming your tables and `User` properties with anything beginning with "Puck" collisions should not occur. also, in terms of `Roles`, all Puck roles start with an underscore - so it's best to avoid that pattern.