Comment 2 for bug 1174610

First fwiw, this is backwards compatibility problem issue. Second, its quite common to associate resources/data to a unit using the unit *id* as both a semantic and unique reference to that allocation. For example associating logging and metric data in an aggregator and visualizer to a unit, ie. like some of our existing monitoring and logging charms. With this change, we're saying that such data would need to be deleted after a relation is broken or that it could be mistakenly associated to a different instance of the same unit id, neither of which is desirable. I don't think exposing another primary key field is particularly helpful, because at this level the semantic value of the unit id is important for human interpretation/correlation of the data, plus an additional primary key would break existing charms that rely on this behavior.