Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom names for sessions tables #180

Open
alexedwards opened this issue Oct 22, 2023 · 3 comments
Open

Custom names for sessions tables #180

alexedwards opened this issue Oct 22, 2023 · 3 comments

Comments

@alexedwards
Copy link
Owner

As per the comments on #177, consider supporting custom names for the sessions tables where it makes sense.

@doggedOwl
Copy link

doggedOwl commented Oct 28, 2023

Table name is an implementation detail of the relational db stores so I think it's fine to implement it store by store like in the PR at #177.

For consistency it may be usefull to add it to all of stores backed by a relational db, more or less the equivalent of the prefix option for the KV stores.

Setting the tablename after init though (using SetSessionsTableName like in #177) does not seem right so maybe it would be better to have a new constructor:
func NewWithOptions(pool *pgxpool.Pool, cleanupInterval time.Duration, tableName string) *PostgresStore

This again mirrors more or less the
func NewWithOptions(client *api.Client, cleanupInterval time.Duration, prefix string) *ConsulStore for example.

@alexedwards
Copy link
Owner Author

I like the idea of a NewWithOptions() approach. Perhaps we could make Options a struct and pass it as a 2nd parameter to allow further options in the future without making breaking changes to the public API. So, for postgresstore for example:

type Options struct {
    CleanupInterval time.Duration
    TableName string
}

Which could then be used like:

postgresstore.NewWithOptions(db, postgresstore.Options{
    CleanupInterval: time.Minute,
    TableName: "mycustomsessions",
})

If any fields in Options are not provided (i.e. they contain the relevant zero value), then we can use a sensible default (i.e. cleanup interval of 5 minutes, table name of "sessions").

I think we could potentially roll this pattern out across all the different stores and deprecate the NewWithPrefix() and NewWithCleanupInterval() functions on the individual stores, leaving each store with two ways to initialize it: either New() (which uses the defaults) or NewWithOptions() which allows you to customize the behavior in whatever way makes sense for that particular store.

The only problem I can see right now is that the consulstore package already has a NewWithOptions() function with a different signature. So we could either:

a. Make a breaking change to consulstore.
b. Not implement the Options struct pattern in consulstore.
c. Think of an alternative name for NewWithOptions(). I'm blanking on a decent name. Any suggestions?

@Kraysent
Copy link

Kraysent commented Dec 14, 2023

That would be a nice feature!

Maybe instead of whole separate constructor one might consider using Functional Options pattern. See pull request #190 for the prototype.

In this case, no backwards compatibility is broken: New(db) will fall back to the same names as now.
If one wants to change the default name (and schema for that matter) of the table as well as column names, they can use nice syntax:

New(db,
  WithSessionTableName("schema.session_table"),
  WithExpiryColumnName("expiry_date"),
  WithTokenColumnName("token"),
  // data column will not change!
)

As a bonus, one may change cleanupInterval the same way (also without breaking backwards compatibility):

New(db, WithCleanupInterval(10*time.Minute))

It seems to me that such implementation would solve all the problems above and is applicable to any other store. Feel free to point at anything I might have forgotten!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants