Currently nd_service_registry.registration.Registration objects are 'greedy' - that is, they believe they own and need to continue to own the content at a given path. That means that if you create a data chunk at /services/myapp/config with supplied data {'foo': 'bar'}, for the duration that your ServiceRegistry object is alive, it will make sure that the configuration at that path looks like {'foo': 'bar'}. This means that if you use another ServiceRegistry object to change the data to {'foo': 'baZ'}, these two ServiceRegistry objects will now start to fight over which data is set at the path. This behavior is counter-intuitive.
What we likely need to do is create a nd_service_registry.registration.Data class that simply sets data at a given path, and nothing else. With this object, we likely need:
A new set_data() method to easily set static data
Updates to the unset() method to handle deleting static data
diranged
commented
10 years ago
Currently
nd_service_registry.registration.Registrationobjects are 'greedy' - that is, they believe they own and need to continue to own the content at a given path. That means that if you create a data chunk at/services/myapp/configwith supplied data{'foo': 'bar'}, for the duration that your ServiceRegistry object is alive, it will make sure that the configuration at that path looks like{'foo': 'bar'}. This means that if you use another ServiceRegistry object to change the data to{'foo': 'baZ'}, these two ServiceRegistry objects will now start to fight over which data is set at the path. This behavior is counter-intuitive.What we likely need to do is create a
nd_service_registry.registration.Dataclass that simply sets data at a given path, and nothing else. With this object, we likely need:set_data()method to easily set static dataunset()method to handle deleting static data