Show extended run-"index" from Platform.meta.tabulate()

[danielhuppmann]

While further working on the pyam-imxp4-integration, I noticed an inconsistency:

• Platform.runs.tabulate() returns a dataframe with the columns run-id, model, scenario, version
• Platform.iamc.tabulate() returns a dataframe with (only) the "user-readable index" model, scenario, version, ...
• Platform.meta.tabulate() returns a dataframe only with (only) the run-id, ...

In actual work (like the pyam-integration), the model-scenario-version is more relevant.

So this PR extends the Platform.meta.tabulate() to return the "extended index" of model-name, scenario-name and version number.

As a utility, the PR also adds a map() endpoint to the model- and scenario-repository for easy translation of id's to names.

If there is a need for having (only) the run-id at the facade/core-layer, I'd be happy to implement that as a kwarg to both iamc/meta tabulate methods (and if someone has a good suggestion for the name of that argument...)

[danielhuppmann]

The implementation follows the approach in Platform.runs.tabulate() where only the id's are queried from the backend and expanded in the core layer. I guess that joining the tables in the ORM-layer would be a viable alternative, not sure if there is a performance difference...

[meksor]

I think there is a strong argument to be made to do this (optionally) in the database layer. Performance wise there is definitely a difference: for big tables I expect faster execution and less memory usage in the database.

There is already similar functionality in the DataPointRepository when supplying join_parameters:

ixmp4/ixmp4/data/db/iamc/datapoint/repository.py

Lines 159 to 173 in 6eead51

	def select(
	self,
	*,
	join_parameters: bool | None = False,
	join_runs: bool = False,
	_filter: DataPointFilter | None = None,
	**kwargs: Any
	) -> db.sql.Select:
	exc = (
	self.select_joined_parameters(join_runs)
	if join_parameters
	else select(self.bundle)
	)
	return super().select(_exc=exc, _filter=_filter, **kwargs)

More detail in select_joined_parameters.

Side note:
Currently there doesnt seem to be the need to implement the map method in both the api and db layer. You can just leave it in the abstract base class since its the same code...

[danielhuppmann]

I think there is a strong argument to be made to do this (optionally) in the database layer. Performance wise there is definitely a difference: for big tables I expect faster execution and less memory usage in the database.

Thanks for the feedback. Just for my understanding, does the faster database-execution outweigh the downside of sending a table twice the size via the Rest API?

[meksor]

That's a good question. My guess: yes, since gzip will hopefully take care of compressing away any repeating patterns and sending a seperate request for the list of all runs also presents some overhead.

[danielhuppmann]

closing in favor of #37