Define and implement name resolution rules

Registered by Steve McLellan on 2014-05-23

Currently FQNs are considered globally unique. This will be inconvenient in cases where multiple tenants wish to install the same package, and/or admins wish to make public certain packages. This also affects classes (and the rules by which the engine resolves the appropriate package for a class).

The suggestion for resolution rules is, in order of precedence:

1) The local tenant
2) Packages shared with the tenant
3) Public packages
4) External packages

The measure of uniqueness then becomes tenant, FQN.

If there is any precedent for this in other projects we should definitely consider that. The only one i can think of is Glance which deals with this in the following way:
* Duplicate names are allowed
* The API will look up an image by name but fail if the name is ambiguous, requiring ID instead

This won't work for us because the ID of a package isn't known in advance, so at the very least there need to be resolution rules within packages. Ultimately this might be something the system can warn about when importing, but for now clearly defined rules should be sufficient.

Blueprint information

Status:
Not started
Approver:
Ruslan Kamaldinov
Priority:
Undefined
Drafter:
Steve McLellan
Direction:
Approved
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Deferred
Milestone target:
None

Related branches

Sprints

Whiteboard

Agree on the precedence order

There should be no conflicts in each category, so the checks should be enforced during package import (to ensure that the current tenant does not own another package with the same FQN), during package sharing (to ensure that no other package with the same FQN is shared with a tenant) and during package publishing (no other public package exist with the same FQN).

Same should go for classes FQNs

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.