Currently ddr-defs/repo_modules are a set of Python modules. This has worked well for us, allowing us to specify fields (as data in a list-of-dicts) and do some custom data handling on a per-field basis using the converters functions.
This doesn't support the following use cases:
specify definitions at runtime (i.e. as a commandline arg)
per-collection (or pre-entity) definitions
This is because the definitions path is specified in DDR.config or (django.conf.settings) and imported whenever DDR.identifier is first imported. Definitions can only be imported once.
If we could separate the custom converters code from definitions, then we could (for example) import multiple definitions files, putting them into some data structure.
We'd have default definitions (of course).
Definitions could be embedded in organization repos, or in collections, or even entities.
Objects could point to definitions at a filesystem path (dangerous) or a URL.
The definitions structure would cache these pointers so they only have to be ingested once per application session.
Currently
ddr-defs/repo_modules
are a set of Python modules. This has worked well for us, allowing us to specify fields (as data in a list-of-dicts) and do some custom data handling on a per-field basis using theconverters
functions.This doesn't support the following use cases:
This is because the definitions path is specified in
DDR.config
or (django.conf.settings
) and imported wheneverDDR.identifier
is first imported. Definitions can only be imported once.If we could separate the custom converters code from definitions, then we could (for example) import multiple definitions files, putting them into some data structure. We'd have default definitions (of course).
Definitions could be embedded in organization repos, or in collections, or even entities. Objects could point to definitions at a filesystem path (dangerous) or a URL.
The definitions structure would cache these pointers so they only have to be ingested once per application session.