feat: Add ent-based sqlite3 storage

[nabokihms]

Overview

This PR adds an ability to switch to experimental ent-based sqlite3 storage

What this PR does / why we need it

Related #1864

There is the first part of the SQL layer refactoring. What this PR does:

• Database schema described using an ORM.
• Add new ORM-based storage for SQLite.
• Manage to mimic most SQL storages logic.
• Utilize best practices of other storages.
• Include conformance tests for the ent-based sqlite3 storage.

Special notes for your reviewer

Following the "one step at a time" ideology, it looks like a good idea to split the refactoring into chunks.
This part has no negative impact and shows the most vital benefits of switching to using ORM.
I will add a full roadmap to the issue mentioned above.

Does this PR introduce a user-facing change?

Users can switch to utilizing the new driver. Unfortunately, there is no doc, neither migration to switch from using sqlite3 driver to sqlite3-ent. It will be implemented in future PRs.

Add an experimental ent-based sqlite3 storage

[sagikazarmark]

Thanks @nabokihms !

I briefly reviewed the PR, here are a couple thoughts:

• Can you please separate the generated code into a different commit? It would make reviewing much easier.
• In the long term, I don't think we want ent to be a new storage type, but one that replaces the existing ones. So here is an idea: either use a build tag for replacing the current implementation with ent or an env var (eg. DEX_ENT_ENABLED or DEX_EXPERIMENTAL or DEX_EXPERIMENTAL_ENT)
• I can see some packages have been updated. I think those should be part of a separate PR.

[nabokihms]

1. Yes, it is possible to exclude all generated code since we already have the generate step in the Makefile.
2. Yeah, I thought about something like an env variable. The thing that stopped me to use it is that Dex had no standardized way to add new env-based settings. However, in this case, it simplifies the switching process, thus I will follow your suggestion.
3. I will double-check this.

[sagikazarmark]

Yes, it is possible to exclude all generated code since we already have the generate step in the Makefile.

I don't think we have to exclude generated code, but putting it in separate commits definitely helps.

[nabokihms]

There are three commits now:

• storage code
• auto-generated code
• dependencies updating required by ent (which will be moved to a separate PR)

[nabokihms]

@sagikazarmark, thanks for updating dependencies and adding dependabot! The only package that left required an update is the MySQL driver. Should I open PR for it?

[nabokihms]

@sagikazarmark I bumped ent version to 0.8.0, resolved conflicts, added support for recently merged settings for refresh tokens.

Dependencies changes look good now.

[sagikazarmark]

LGTM!

[sagikazarmark]

@nabokihms Feel free to merge it if you think it's ready.

[sagikazarmark]

🎉

[a8m]

Happy to see this PR! 🥳

Please, feel free to tag me on GitHub or ping me in ent Slack channel if you need any support for Ent.

[sagikazarmark]

Thanks @a8m !

We are still experimenting with ent here, but I followed the project for quite some time now and it's amazing (by far the best Go ORM).

One thing that's going to be a concern is migrations (not very familiar with how ent does that yet) in a production environment.

[a8m]

We're working now on a new migration platform for ent that will cover 99% of the cases. I'll be happy to get your feedback or just to hear your thoughts before we're OSS-ing it. Thanks 🙏

[sagikazarmark]

When it comes to migration, I'm always worried about automated migrations:

• What if something goes wrong?
• How do you roll back?
• Can you even roll back?
• How does the underlying database (eg. MySQL) cluster handles schema changes?
• What if the database user doesn't have the permissions to do schema changes (for security reasons)?
• What happens when multiple instances of the same service spawns (eg. during a deployment) and they all try to run the migrations?

Therefore when working for large systems, I always insisted on having a separate, manual process available for migrations. Not just that, but it was also mandated that these changes must be backward compatible between two subsequent versions. For example: if you wanted to delete a column from the database, first you needed to remove any code using that column (version 1) and in the next release (or rather before deploying it) you were allowed to add a migration step that removed that column.

I think there is no good solution available for these issues, especially in the Kubernetes/Cloud Native world (where Dex is mostly used). That being said, we also use automatic migrations in Dex, because it's just easier. But I'd love to see a solution where we can give operators the means to manually run migrations prior to deploying a new version or at least see some tooling that can help with recovering from a bad state.

@a8m These are my thoughts about migration. Hope it helps a bit.