Merge lp:~jameinel/juju-core/typed-registry into lp:~go-bot/juju-core/trunk
Status: | Merged |
---|---|
Approved by: | John A Meinel |
Approved revision: | no longer in the source branch. |
Merged at revision: | 2739 |
Proposed branch: | lp:~jameinel/juju-core/typed-registry |
Merge into: | lp:~go-bot/juju-core/trunk |
Diff against target: |
298 lines (+278/-0) 4 files modified
utils/registry/export_test.go (+8/-0) utils/registry/package_test.go (+14/-0) utils/registry/registry.go (+105/-0) utils/registry/registry_test.go (+151/-0) |
To merge this branch: | bzr merge lp:~jameinel/juju-core/typed-registry |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Juju Engineering | Pending | ||
Review via email: mp+219161@code.launchpad.net |
Commit message
utils/registry: TypedNameVersion registry
As part of getting API versioning in place, I was putting together some
Registry's in a couple of places. I realized I wanted 2 things that were
essentially identical code, just tracking slightly different object
types. So I put together an abstraction that still enforces the Type,
but is otherwise treats the input and output as a generic interface{}.
Description of the change
utils/registry: TypedNameVersion registry
As part of getting API versioning in place, I was putting together some
Registry's in a couple of places. I realized I wanted 2 things that were
essentially identical code, just tracking slightly different object
types. So I put together an abstraction that still enforces the Type,
but is otherwise treats the input and output as a generic interface{}.
I'm not stuck on the naming, though I went with
registry.
easily calling simply registry.Registry and the fact that it enforces
Types and uses Name+Version as the key can just be in the docs.
I'm not 100% sure that we'll strictly need this, as the code is evolving
to where I may only have 1 registry. However, it still seemed like a
useful bit of functionality, and it was easily split out from the other
work as a self-contained and well tested bit of work.
If we prefer, I can wait to land this until it is clearly necessary
(rather than just having a single Registry that has a fixed object
type). But if we ever have >=2 registries with different types, I think
we'll want something like this.
Reviewers: mp+219161_ code.launchpad. net,
Message:
Please take a look.
Description:
utils/registry: TypedNameVersion registry
As part of getting API versioning in place, I was putting together some
Registry's in a couple of places. I realized I wanted 2 things that were
essentially identical code, just tracking slightly different object
types. So I put together an abstraction that still enforces the Type,
but is otherwise treats the input and output as a generic interface{}.
I'm not stuck on the naming, though I went with TypedNameVersio n as the handle for this thing. I could just as
registry.
easily calling simply registry.Registry and the fact that it enforces
Types and uses Name+Version as the key can just be in the docs.
I'm not 100% sure that we'll strictly need this, as the code is evolving
to where I may only have 1 registry. However, it still seemed like a
useful bit of functionality, and it was easily split out from the other
work as a self-contained and well tested bit of work.
If we prefer, I can wait to land this until it is clearly necessary
(rather than just having a single Registry that has a fixed object
type). But if we ever have >=2 registries with different types, I think
we'll want something like this.
https:/ /code.launchpad .net/~jameinel/ juju-core/ typed-registry/ +merge/ 219161
(do not edit description out of merge proposal)
Please review this at https:/ /codereview. appspot. com/99180044/
Affected files (+280, -0 lines): export_ test.go package_ test.go registry. go registry_ test.go
A [revision details]
A utils/registry/
A utils/registry/
A utils/registry/
A utils/registry/