389-ds-base

#48820 lib389: Make consistent set/get properties api

Closed: wontfix None Opened 7 years ago by firstyear.

Right now we have a very inconsistent api for lib389 get and set properties.

For example, in lib389/changelog.py, we have:

def setProperties(self, changelogdn=None, properties=None):
...
   for prop in properties:
      if str(prop).startswith('+'):
          op = ldap.MOD_ADD
 ....

In other places:

https://fedorahosted.org/389/attachment/ticket/48663/0001-Ticket-48663-Implement-get-and-set-properties-for-ba.2.patch

to:

lib389/backend.py

raise NotImplemented

They all take different arguments to identify the resource we are working on. Some of these are singleton, some of these take dns, some are entries, some take a variety of data points.

I think that we can make this better.

For singleton, we can have a base type that is subclassed. This would define the DN of the relevant configs, and the set/get prop methods done to take a dictionary of values that is consumed by ldap modlist. This way, we can much more easily drop in / out changes, and unify how we access some configs. This doesn't preclude wrapping some common ops in wrappers that just call get/set for convinence, and in fact, makes it easier to do.

For types with multiple instances (say backends, replication agreement), we can have a get backend / create backend parent that selects the correct backend. This then acts like a factory to hand back an instance of the backend with the singleton type, and the dns all set correctly. From there we can just use the same methods.

Essentially. I imagine something like:

standalone.changelog.setProperties({'nsslapd-changelog-triminterval': '5'})
standalone.encryption.enable()
# Under the hood this would call self.setProperties({nsslapd-secure: on}) etc.

be = standalone.backend.get(suffix="dc=example,dc=com")
be = standalone.backend.get(name="userRoot")
# This uses the factor pattern to select and return the right be.
be.setProperties({'dbcachememsize': '9001'})
# Now we can set properties
be.enable_readonly()
# We can still have specific functions for the type that just calls get/set underneath.

Question: Won't this break things?
Answer: Probably. Our tests are pretty inconsistent, we have some that call these helpers, some that call direct ldap mods. But in the long term, making this cleaner, and more consistent is going to make all our lives easier. It means we won't need to work so hard to add new resources. For example, we could add a new resource with as little code as:

class SomePluginConfig(LdapConfigObject):
    def __init__(self)
        self.dn = 'cn=someplugin,cn=plugins,cn=config'

And bang, we have a type that inherits get/set properties, and we can probably even start to think about some debug, listing and other nice base types to include.

Question: But things work, why do you want to change it?
Answer: with rest389 on the horizon, it's becoming more apparent that if we are to clean up and polish lib389, now is the time to do it before we are too far dependent on it's quirks.

389-ds-base

Source Code

#48820 lib389: Make consistent set/get properties api Closed: wontfix None Opened 7 years ago by firstyear.

self._instance = conn

self._instance = conn

Metadata

#48820 lib389: Make consistent set/get properties api

Closed: wontfix None Opened 7 years ago by firstyear.