Allow already prefixed fields to be configured as provider fields #1720
Conversation
ml-evs
added
server
Codecov Report
@@ Coverage Diff @@
## master #1720 +/- ##
=======================================
Coverage 90.87% 90.87%
=======================================
Files 74 74
Lines 4615 4615
=======================================
Hits 4194 4194
Misses 421 421
Flags with carried forward coverage won't be shown. Click here to find out more.
|
ml-evs
force-pushed
the
ml-evs/allow_prefixed_fields
branch
from
7b1237c to
5cd3d99
Compare
ml-evs
force-pushed
the
ml-evs/allow_prefixed_fields
branch
from
5cd3d99 to
867cdf3
Compare
| @@ -255,6 +255,8 @@ def all_fields(self) -> Set[str]: | |||
| # All provider-specific fields | |||
| self._all_fields |= { | |||
| f"_{self.provider_prefix}_{field_name}" | |||
| if not field_name.startswith("_") | |||
There was a problem hiding this comment.
I was wondering could some databases not already have internal field names starting with an underscore, but not a valid prefix ?
In that case, it would be better to check if a whole prefix is present.
There was a problem hiding this comment.
They could, but unless they define the field in their config then it won't show up anyway. Either way, they should be able to access those fields (they cannot currently) and can configure a mapper to choose a better field name.
There was a problem hiding this comment.
Yes that is true, I think I used a field name with an underscore to transfer information that was relevant for processing an entry but not useful to share with the users.
|
I was still wondering, could you perhaps also add a test for queries? So that we can be sure that these fields are also handled correctly in queries. |
The validator tests should be taking care of this; every field reported in the |
This PR allows provider fields to be put into the config that already contain the prefix. This can eventually be extended to cover definition providers too.
This is useful for the case where a local database has already been prepared with OPTIMADE in mind, and thus database fields already contain the relevant prefix, to avoid adding the prefix twice.