Next-auth: Update and document models, schemas and database structure

[iaincollins]

Summary of proposed feature

We need to improve the the models and schemas to get them production ready, and document what they are for the various supported databases.

Purpose of proposed feature

The models are some missing fields and indexes you'd expect and they are not documented.

Detail of the proposed

• [x] Update Models and Schemas to be production ready (good default names, behaviour, etc)
• [x] Review all types and indexes across supported databases
• [x] Add created at, updated at properties to all models
• [x] Add email verified property to User model
• [x] Document all models and schemas
• [ ] Document how to extend models and schemas
• [x] Document database schemas for supported databases (automate generating these)
• [x] Consider applying snake case naming strategy for SQL databases (see also this example) by default (and/or option).
  This would need need some fairly extensive cross database testing as it may introduce subtle bugs.

Potential problems

This will need extensive testing.

I would love people to volunteer to help if you are using any of the following:

• MySQL
• Postgres
• MariaDB
• MongoDB
• Any other SQL DB

Describe any alternatives you've considered

N/A

Additional context

This was deliberately left till quite late as we didn't know what we'd need until we got to this point.

[LoriKarikari]

I'd like to help but I don't really have time this week. I use MongoDB, Postgres and MySQL/MariaDB so can help with testing those too. I'm not really familiar with TypeORM as I mostly just use raw SQL but can look into that. Do you also want to include migrations? Or just provide docs of the db design and let users handle migration themselves with a library of choice?

[iaincollins]

I think I'm trying to avoid migrations, by allow the beta to have breaking changes, getting it right for launch then worrying about it when we need to after launch.

I have researched migrations in TypeORM and tried them out a bit and I'm fairly comfortable that it's not going to be too hard, it just feels like too much to also do right now if we don't need it.

As well as helping folks understand how it works, I think having good documentation would save us from having to worry about migrations for a while; even if we do make a small change later that seems like something we could cover in a change log (e.g. "change X column to Y if upgrading").

Thanks for any more help you can offer, but don't worry about finding time! I'm only putting so much time in because I need to resolve some issues this month on other projects that doing all this helps with.

I'm hoping folks in the community can help us by letting us know what software they are using and what providers they have tried, what options they had set. I was thinking we could maybe do a Google Survey to gather info record the result in a Google Sheet, I know ordinarily >90% of the people watching / looking / using at a project don't ever post on them.

[LoriKarikari]

Okay, I'll see what's been worked on and help where I can somewhere next week.

[iaincollins]

I'm happy to close this as is resolved by PR #253 - with the exception of documenting how to extend models and schemas, which I can follow up on.

Testing of the new schemas and models is of course still very relevant and I've sticked #254 to ask for feedback on them.