Unique names enforced only within object classes about spine-database-api HOT 14 CLOSED

In GitLab by @Antti-L on Mar 13, 2019, 18:57

Yes, I would agree; allowing that would obviously reduce potential issues with importing model databases from other systems like GAMS, where any single label can be a member of many sets, including the basic domain sets.

from spine-database-api.

In GitLab by @manuelma on Mar 13, 2019, 20:35

I don't see any big problems either...

from spine-database-api.

In GitLab by @manuelma on Mar 13, 2019, 21:11

I also heard the similar was desired for parameter names (uniqueness only within the same object class). Thoughts?

from spine-database-api.

In GitLab by @jkiviluo on Mar 14, 2019, 11:05

Yes, parameters should also be allowed to be the same in two different object_classes or relationship_classes.

from spine-database-api.

In GitLab by @manuelma on Mar 25, 2019, 12:46

I will implement this now, since nobody seems to think it's a bad idea...

from spine-database-api.

In GitLab by @manuelma on Mar 25, 2019, 15:34

mentioned in commit 01fd467

from spine-database-api.

In GitLab by @PvPer on Mar 25, 2019, 15:58

These should be updated in the SQL table definitions to if you havn't already, unique(class_id, object_name) etc.

from spine-database-api.

In GitLab by @manuelma on Mar 28, 2019, 16:48

I just realized one difficulty in allowing same parameter names in different relationship classes: JuMP_all_out generates parameter access functions that are called like

parameter1(object_class1=object1, object_class2=object2)

Obviously this doesn't work anymore, since the relationship class is no longer implicit. In other words, there could be a relationship between object1 and object2 in two different relationship classes, both having a parameter called parameter1, and there would be no way of telling the difference with the above formulation.

So now, the function would need to be called as follows:

parameter1(relationship_classx=(object1, object2)) which I hope is not too bad.

from spine-database-api.

In GitLab by @manuelma on Mar 28, 2019, 18:05

mentioned in commit SpineInterface.jl@7f78fd641e722ac3b8684b081235e869d766ed28

from spine-database-api.

In GitLab by @manuelma on Mar 28, 2019, 20:11

mentioned in commit SpineInterface.jl@99657138069b1ab5cb2fb6f7fa61410d42585c1f

from spine-database-api.

In GitLab by @PvPer on Mar 29, 2019, 09:15

I guess you could do something like this in julia:

struct Unit
    param1::Function
    param2::Function
end

function (::Unit)()
    println("return all objects in unit class")
end

for u in Unit()
   param_value = Unit.param1(unit=u, t=1)
end

Might be a bit clearer to read, have not tried so might have some other complications.

or maybe something like this, here we wont have to worry about rules for parameter names:

Unit.parameter(param=:unit_efficiency, unit=:CoalPlant)

from spine-database-api.

In GitLab by @manuelma on Mar 29, 2019, 12:50

You don't like this?

parameter1(relationship_classx=(object1, object2), t=t)

I tried it, and in code you have something like

capacity(unit__commodity=(u, c), t=t)

which I think is fine?

Your idea is also good, although a bit less compact:

unit__commodity.capacity(unit=u, commodity=c, t=t)

from spine-database-api.

In GitLab by @manuelma on Apr 9, 2019, 02:14

I'll close this as it seems to be working, please open new issues for reporting problems.

from spine-database-api.

In GitLab by @manuelma on Apr 9, 2019, 02:14

closed

from spine-database-api.