spine-tools / Spine-Database-API

Database interface to Spine generic data model
https://www.tools-for-energy-system-modelling.org/
GNU Lesser General Public License v3.0
6 stars 5 forks source link

Drop object and relationship and keep only entity #215

Open manuelma opened 1 year ago

manuelma commented 1 year ago

This will be the first of a series of issues about data structure and API updates begining with Mopo.

This first big change is both a data structure change and an API change. We will drop the object and relationship tables and have everything in the entity table (I won't say it explicitely but everything I say about object, relationship and entity will of course also apply to object_class, relationship_class and entity_class).

The only thing that will tell the old object and relationship apart is the dimensionality (0 in the case of an object, 1 or more in the case of a relationship). So in the end, we would just have entities with different dimensionality and that is supposed to allow both users and us to reason about the data structure much easier. Also some API calls will look more compact.

This change will be reflected in the API so instead of dealing with objects and relationships, the API user will deal exclusively with entities. And this of course means the UI needs to also be updated to present stuff in terms of entity rather than object and relationship. This will be a big change and needs to be done gradually. My plan is the following:

  1. [x] Upgrade the DB structure: drop object and relationship tables
  2. [x] Upgrade the current API to work with the entity table rather than with the object and relationship tables. At this point, the API will remain unchanged so all the clients, including UI, will continue to work, look and feel as they do today.
  3. [x] Implement new API to manipulate entities directly (rather than manipulating objects and relationships separately)
  4. [x] Gradually upgrade clients (UI, import mapping, export mapping, SpineInterface, long etcetera) to use the entity API in places where they are using the object/relationship API
  5. [ ] Add deprecation notices to the old API that deals with objects and relationships.
  6. [ ] Pray that all API users (including ourselves in our own institutions) also upgrade their calls to use the new entity API.
  7. [ ] Fast-forward one year or more in the future. Remove the old object and relationship API if it bothers us.

I added 'if it bothers us' at the end because the old API may prove maintainable and in that case we can save us a huge headache.