remove OptionalValueException?

[sanderr]

Make sure to read comments below, ticket description has not been updated

Currently an OptionalValueException is raised when an optional relation attribute is accessed that has not received a value or has received an explicit null value. This is inconsistent with the behavior for nullable plain attributes and that for multi relations, which result in null and [] respectively. The goal of this ticket is to investigate the feasibility and discuss the value of dropping the OptionalValueException and returning null instead. When attempting to access an attribute/relation of the null relation, an OptionalValueException should still be raised.

As a next step, we could consider deprecating is defined in favor of != null / != [].

[sanderr]

A non-exhaustive (exhaustive within the set of repos checked out on my system) overview of how this would affect other projects (assuming we keep the exception class around):

• changes Jinja's is defined behavior: null is considered defined, while the OptionalValueException was not. For models to be compatible with both old and newer versions of core, they would need something like x.y is defined and x.y is not null.
• The lsm module catches the exception in some places. Mostly this is just to convert it to None (the change would be compatible with those) but in some cases the logic really branches on it.
• Same for the yang module.
• std uses it in compatible ways (except for the Jinja part)
• openstack uses it in compatible ways
• internal docs uses it in an example
• pytest-inmanta uses it in a test module (module used to test pytest-inmanta, not something used by the actual pytest plugin)

So the main consequences are that lsm and yang need minor changes, as well as any module that uses is defined on optional relations. These changes could be made in backwards compatible ways so that we have the following compatibility constraints:

• iso6 requires patched versions of lsm, yang and other relevant modules
• iso5- is compatible with module versions before and after the patch

[sanderr]

Concluding: it's defintely not trivial and it may cause some fallout but it should be doable. Question is, do we want it sufficiently badly to do it now, before the iso6 release, or do we keep it for iso7?

[sanderr]

Planning meeting conclusion: delay this until a couple of months before the next major, migrate modules before that. I will create tickets for this and put them in the appropriate epics.

[sanderr]

I will create tickets for this and put them in the appropriate epics.

inmanta/lsm#546
inmanta/infra-tickets#170
kept this one for the main change