Bug 52438 - make UCR initialization chainable
make UCR initialization chainable
Status: RESOLVED DUPLICATE of bug 51126
Product: UCS
Classification: Unclassified
Component: UCR
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-27 12:58 CET by Daniel Tröder
Modified: 2020-11-27 16:13 CET (History)
2 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): API change
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Tröder univentionstaff 2020-11-27 12:58:05 CET
This code can be seen in almost all UCS software:

    ucr = ConfigRegistry()
    ucr.load()

It'd be shorter to write this instead:

    ucr = ConfigRegistry().load()

For that the univention.config_registry.backend.ConfigRegistry.load() method must simply return 'self'.

Apart from slightly shorter code, this is foremost interesting to replace module level execution of I/O code (ucr.load()) with a lazy function:

    ucr = lazy_object_proxy.Proxy(lambda: ConfigRegistry().load())


The UCS@school lib already uses such a construct for a single, lazily loaded() UCR instance (that is used by most of the UCS@school code).

ucs-school-lib/python/models/utils.py:104

The API change is IMHO OK, as I don't expect any code to depend on the old return value of load() to be 'None'.
Comment 1 Philipp Hahn univentionstaff 2020-11-27 14:08:17 CET
See Bug #51126 for "Shared lazy-loaded read-only ConfigRegistry singleton"
Comment 2 Daniel Tröder univentionstaff 2020-11-27 16:13:41 CET
(In reply to Philipp Hahn from comment #1)
> See Bug #51126 for "Shared lazy-loaded read-only ConfigRegistry singleton"
Oh… I totally forgot about that.
I'll retract this bug in favor of the existing one.

*** This bug has been marked as a duplicate of bug 51126 ***