Currently we provide procuring_entities_details and suppliers_details routes where people can receive aggregated data and analysis on different suppliers or procurers.
We also need relationship details as described in tenders-exposed/elvis-ember#201.
In our current backend this would be quite difficult to make because the relationship between 2 entities is not represented as a separate entity and is not stored in the database. This will change when we switch to a graph database and edges will finally be stored.
Our current REST interface also makes it hard to represent relationship details because people can query by suppliers or procurers only in bulk:
From @georgiana-b on October 16, 2017 6:15
From @georgiana-b on May 26, 2017 13:9
Currently we provide
procuring_entities_details
andsuppliers_details
routes where people can receive aggregated data and analysis on different suppliers or procurers. We also need relationship details as described in tenders-exposed/elvis-ember#201.In our current backend this would be quite difficult to make because the relationship between 2 entities is not represented as a separate entity and is not stored in the database. This will change when we switch to a graph database and edges will finally be stored.
Our current REST interface also makes it hard to represent relationship details because people can query by suppliers or procurers only in bulk:
So, we have to take this into consideration in the new REST interface and provide a way to query by a relationship.
Copied from original issue: tenders-exposed/elvis-backend#54
Copied from original issue: tenders-exposed/elvis-backend-py#13