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 DbContexts, 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.