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

Support multi-D entities where the elements are also multi-D entities #291

Closed manuelma closed 11 months ago

manuelma commented 11 months ago

This is coming almost for free with the new DB schema since we relaxed the constraint that relationships needed to be composed of objects. Now entity elements can be any entities.

But we probably need to extend import_entities so it works with multi-D entities where the elements are also multi-D entities.

jkiviluo commented 11 months ago

I suppose we need to require different class names even if the dimensions match? And that's not a bad requirement in any case.

manuelma commented 11 months ago

Yes, class names are unique.

DillonJ commented 11 months ago

We discussed this a little and you could possibly depart from the convention we have been using thus far to better capture the meaning of the multi-d entity... e.g. unit_input_flow__unit_output_flow rather than unit__to_node__unit__from_node otherwise, you might need a new convention to signal it's a multi-d entity mith multi-d entities as members. E.g. unit__to_node|unit__from_node

jkiviluo commented 11 months ago

Another option is to do unit__input_flow____unit__output_flow. I think we need to be really careful about this - it will be long lasting and can be a source of confusion.

soininen commented 11 months ago

Can you use the entities of these multi-D entity classes as dimensions in even higher-D classes?

manuelma commented 11 months ago

Can you use the entities of these multi-D entity classes as dimensions in even higher-D classes?

Yes, it never stops. So the dimensions could be themselves entity classes where the dimensions are entity classes where the dimensions are themselves entity classes, and so on

soininen commented 11 months ago

Yes, it never stops.

Should we take it into account with the naming convention? I know underscores are everybody's favorite, but how about some brackets? [[unit__input_flow][unit__output_flow]]?

manuelma commented 11 months ago

Brackets are problematic for SpineInterface, unfortunately. The only thing that works is underscores.

Edit: exclamation points work also. And this: ¤

soininen commented 11 months ago

Sounds like we are on the fast track to underscore heaven, then :P

And this: ¤

I can't even find that one on my keyboard!

DillonJ commented 11 months ago

This discussion reminds me of the | that is used in toolbox to delimit objects in a relationship... it so happens that it's not the | that one finds on one's keyboard, but rather, a character that can only be reproduced by pasting the character into notepad or somewhere and copying it from there

manuelma commented 11 months ago

This discussion reminds me of the | that is used in toolbox to delimit objects in a relationship... it so happens that it's not the | that one finds on one's keyboard, but rather, a character that can only be reproduced by pasting the character into notepad or somewhere and copying it from there

I'm curious why people need to use that character?

soininen commented 11 months ago

I'm curious why people need to use that character?

You can paste a table directly to the Relationship parameter value table, if you get your vertical bars | right.

Edit: I think SpineOpt tutorial does this and it fails because the tutorial uses commas.

DillonJ commented 11 months ago

This discussion reminds me of the | that is used in toolbox to delimit objects in a relationship... it so happens that it's not the | that one finds on one's keyboard, but rather, a character that can only be reproduced by pasting the character into notepad or somewhere and copying it from there

I'm curious why people need to use that character?

If I want to paste parameter values into the parameter value pane - I need to recreate the entity list. This is key functionality we should preserve when thinking about how it will work in the future

Edit: Ah @soininen was in first :-)

manuelma commented 11 months ago

Ah, thanks

So my initial idea was to use that bar only for displaying data, but whenever the user would copy the data, it would be separated by comma. I guess that changed at some point without me noticing it and now the user needs to deal with that bar.

In my keyboard I can type that bar, must be a windows vs linux thing.

So I guess we need another issue for the bar problem?

DillonJ commented 11 months ago

Are you sure it's the same bar? I can type a bar |||||| but they're not the right bars

manuelma commented 11 months ago

Are you sure it's the same bar? I can type a bar |||||| but they're not the right bars

No, they are different. My key maps to another character than yours.

manuelma commented 11 months ago

I think this works now.