-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make DB Backend Aligned with ICAT Backend #213
Labels
Comments
This was referenced Apr 26, 2021
MRichards99
added
wontfix
This will not be worked on
db backend
Issues relating to the DB backend
labels
Mar 17, 2022
Adding the wontfix label to this issue - there's no plans to work on this issue for the time being and because the DB backend won't be used in production, this is a low priority, potentially high effort issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Description:
A previous issue (#205) changed the database backend to use camelCase, where SNAKE_CASE was previously used. This was a good step to make the two backends aligned with one another, but they are not fully aligned. The two should be be fully interchangeable, allowing them to be used on DataGateway without having to change the frontend each time the API backend is changed.
The differences between the backends remain with foreign keys and related entities. DB backend uses foreign keys (due to its direct connection to DB tables) whereas ICAT backend does not. On DataGateway, I tried to keep foreign keys in, but I encountered naming collisions. For example, I tried to make a related entity called
facility
and also make the foreign key calledfacility
but (obviously) the frontend doesn't like that because two attributes can't have the same name in one class. This was not an issue within the API due to where the names (of related entities specifically I think?) are defined.I think to make the DB backend aligned with the ICAT backend (in that order), the foreign keys need to be removed. Or at least some modification to the foreign keys so that stuff is done in the background (i.e. they don't get returned to the user and they aren't required when updating/creating data in a request).
In theory, if the two backends are fully aligned, the tests which use a Flask test client could be merged into one. Currently, there are two sets of these tests - one for DB backend, another for ICAT backend. The single set of tests can then be parameterised to get both backends running on it). It was my hope to merge these when I camelCased the DB backend, but I couldn't get the full alignment so I chose to keep the separate set of tests.
I'm not sure how all this can be done at the moment, we might need to have a wider discussion to make some form of plan.
Acceptance criteria:
The text was updated successfully, but these errors were encountered: