cc @mehmetgiritli & @alex-belozerov
It would be nice to have a mechanism to adjust filters before sending them when using custom fields. As an example, when querying a structures endpoint for custom fields e.g. band_gap, we would like to be able to control how that field gets mapped depending on the database being queried. In the simplest case, if someone asks to filter band_gap, then each database-specific prefix can be added so that COD recieves a query for _cod_band_gap, MP receives _mp_band_gap and so on. This avoids the user needing to construct some contorted query for _cod_band_gap > 0 OR _mp_band_gap > 0 for an indeterminate number of prefixes.
This could be straightforwardly implemented by parsing the filter and checking whether fields exist within the standard, then simply prefixing them if not.
In the more general case, it would also be very helpful to perform arbitrary mapping of field names programmatically, which could e.g., map bandgap to _cod_band_gap (note the field name is not the same), and potentially even map input values to reflect differing unit definitions. This could either be via some kind of local mapping or just by allowing general preflight callbacks that can define arbitrary logic (similar to the response callbacks we allow now).
I'm not sure if this is exactly we had in mind in discussions, so please do give your thoughts! This would be a very useful feature, so I'd be happy to help, but if you want it sooner rather than later it might be wise if someone took the lead on developing it.
cc @mehmetgiritli & @alex-belozerov
It would be nice to have a mechanism to adjust filters before sending them when using custom fields. As an example, when querying a structures endpoint for custom fields e.g.
band_gap, we would like to be able to control how that field gets mapped depending on the database being queried. In the simplest case, if someone asks to filterband_gap, then each database-specific prefix can be added so that COD recieves a query for_cod_band_gap, MP receives_mp_band_gapand so on. This avoids the user needing to construct some contorted query for_cod_band_gap > 0 OR _mp_band_gap > 0for an indeterminate number of prefixes.This could be straightforwardly implemented by parsing the filter and checking whether fields exist within the standard, then simply prefixing them if not.
In the more general case, it would also be very helpful to perform arbitrary mapping of field names programmatically, which could e.g., map
bandgapto_cod_band_gap(note the field name is not the same), and potentially even map input values to reflect differing unit definitions. This could either be via some kind of local mapping or just by allowing general preflight callbacks that can define arbitrary logic (similar to the response callbacks we allow now).I'm not sure if this is exactly we had in mind in discussions, so please do give your thoughts! This would be a very useful feature, so I'd be happy to help, but if you want it sooner rather than later it might be wise if someone took the lead on developing it.