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

all: Introduce database backend interface and update plugin system an… #956

Merged
merged 1 commit into from Aug 2, 2018

Conversation

someone1
Copy link
Contributor

…d boostrap accordingly (#949)

Signed-off-by: Prateek Malhotra someone1@gmail.com

Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like this, great work! I think there should be tests for the different backends. You might want to have a test suite that simply checks if all of the instantiators work and (optionally) maybe run one or two functions in there. You could probably use the interface as the range struct like

for _, tc := []BackendManager{
  memory...
  sql...
} {
  t.Run(/* ... */ )
}

Apart from that and the things mentioned in the comments I think this is good to go.

panic("Unknown connection type.")
}
return nil
expectDependency(c.GetLogger(), ctx.Hasher, ctx.Connection)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't really need the ctx.Hash/logger dependencies here. This could be the case for plugins for example (they might use a different hasher). I think it would make more sense to put expectDependency in the concrete implementations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm - so move the function and all calls to config and call it as required there, e.g. for the SQL Manager? I'm not entirely sure why these were added so I just copied them back as best I could.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that some services have dependencies to others. In some cases (in the past) these had not been properly instantiated during the set up of a particular service/manager. This caused nil point exceptions (see #928 for example). To solve that I added this little helper that makes sure that no dependency is nil.

Adding this to the SQL or Memory Managers (where required) prevents that.

config/config.go Outdated
}
connection = backend
} else {
c.GetLogger().Fatalf(`Unknown DSN "%s" in DATABASE_URL: %s`, scheme, c.DatabaseURL)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should read: Unknown DSN scheme "%s" in DATABASE_URL "%s\", schemes %v supported

bmutex sync.Mutex
)

type BackendManager interface {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Connection or Connector would be a better choice here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, so BackendConnector then? Any thoughts on what variable we should load from the database plugins? I'm using Manager right now but can update this to Connector to match this name change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, BackendConnector or Connector both work fine. Choose one you like. The plugin should export the same name, so also either BackendConnector or Connector.

@someone1
Copy link
Contributor Author

someone1 commented Aug 2, 2018

Updated though one thing to note is dependency checks are still used in cmd/server unrelated to injecting so I basically just copied this out to config and left it there.

…d boostrap accordingly

Signed-off-by: Prateek Malhotra <someone1@gmail.com>
@aeneasr
Copy link
Member

aeneasr commented Aug 2, 2018

Updated though one thing to note is dependency checks are still used in cmd/server unrelated to injecting so I basically just copied this out to config and left it there.

That makes total sense and is much cleaner. Thank you for your work on this, I truly think this is a step forward to re-usability and customization of Hydra and I really like the design you chose. Thank you for this contribution!

@aeneasr aeneasr merged commit 4ea7496 into ory:master Aug 2, 2018
@someone1 someone1 deleted the 949-plugin-update branch August 2, 2018 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants