You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The old backend uses different column names in places. We could change the code to match the old column names.
Note however that the REST API uses quite different names. This means we would have to write a lot of custom code just to translate the column/field names back and forth in serialization, and it servers no purpose as far as I can see. We should consider whether that is worth it, or whether we are better off renaming the model fields to what is used in the REST API.
The text was updated successfully, but these errors were encountered:
Fair point.
Assuming we match the table names (which is easy to do, see #5) we have two major options for the field names.
Match the fields to the old database. This will keep any services alive that operate directly on the database but it means the new back-end needs to do a lot of special case code just to translate database fields into differently-named REST API data structures.
Change the field names to those which are used in the REST API. This would mean less special-case code in the back-end, but will impact services that operate directly on those fields unless those services are adapted to the new field names.
My hope is that any other services do not actually operate on those fields served by the REST API (i.e. the map server might not be concerned with user data but rather with tracks or just points and lines). That would make a strong case for option 2.
The old backend uses different column names in places. We could change the code to match the old column names.
Note however that the REST API uses quite different names. This means we would have to write a lot of custom code just to translate the column/field names back and forth in serialization, and it servers no purpose as far as I can see. We should consider whether that is worth it, or whether we are better off renaming the model fields to what is used in the REST API.
The text was updated successfully, but these errors were encountered: