Non-core datatypes have no way to define how they are displayed in spatial views attributes

[aj-he]

Arches spatial views depend upon datatypes having a long-lived database function for creating the display values, and core has these built in for "core" datatypes. The fall back is to display the content of the tile node value, which only works if that is non-localized string like, such as the BNG datatype in Arches for HERs.

The new Reference datatype for Arches controlled lists (ACL) is not in "core", but will be a key datatype as the system moves from the RDM to ACL. It has a jsonb value that will not display nicely, so will need a database function to transform to a display value.

Arches core needs a mechanism for Developers creating datatypes to also create db function that is then callable by the spatial view functions to create a display function.

[jacobtylerwalls]

Arches core needs a mechanism for Developers creating datatypes to also create db function that is then callable by the spatial view functions to create a display function.

Maybe we want to encapsulate this in a migration operation, following discussion with @bferguso @robgaston and others re: "operationalizing" graph/datatype changes.

[robgaston]

There was some discussion (though I am unable to find an issue related to this if such an issue exists at the moment) around the need for a single source of truth when it comes to tile display values. The existence of separate logic to generate display values in the database and the application has resulted in drift which could be avoided by having a single source of truth. An idea that was proposed which might be useful here would be to maintain tile display values either in the tiles table or in another table using centralized logic (per data type) when writing data and then always read display values from these stored records. This could have some added benefits in terms of read performance.

[aj-he]

@jacobtylerwalls - yes, I think this follows the discussion in Belfast where we should be developing migration utilities for core elements that ensures a supported route forward.

@robgaston - I had two initial thoughts...

1. provide a pattern for developing datatype display name functions for the database following how the current core datatype function works. Then use a datatype slug to find a call it as the spatial view attribute tables updated by a tile create/edit.
2. Or scrap the DB display value functions and do as you said - create a tiles_display table that will generate the values ready to be consumed.

The first option would be simpler to implement from my perspective, but shift right a load of the complexity to the datatype developer. They'd need to duplicate and maintain the logic two locations, plus write additional tests etc. They would also lose access to python libraries they may have used in the application modules. This may be the quick fix for the Reference datatype.

The second option would require an overhaul of the spatial view database objects (albeit made fewer), and a chunk of work to manage the "display_tiles" lifetime against the tiles (or perhaps a function of indexing?). We would significantly increase the size of the DB, especially where more than one language is used. As you said, I think that a number of areas could benefit performance wise putting this in place. You would move the expense of creating the display value to the save event rather than read. It would also totally remove the need for datatype developers to create a seperate DB function and associated tests etc.

[jacobtylerwalls]

Related: a proposal in archesproject/arches-querysets#25 that would have datatypes "declare" via a SQL fragment how to extract display values from tile data.