Bug? UC_ATTR not shown in Browse

[Antti-L]

Dear VEDA developers.

I just tested with 1.238.1.1, defining a UC with UC_ATTR.  However, I could not see the UC_ATTR in Browse, just like reported also by Lukas here:  https://forum.kanors-emr.org/showthread.php?tid=904

UC_ATTR does not even appear in the Attribute pane, and does not appear when listing all attributes of the Scenario (by selecting the Scenario name and hitting Browse).  It neither appears in the Items Detail for the UC

Two questions:
1.  Is this a bug or am I missing something about using Browse / Item Details?
2.  The UC_ATTR is written otherwise correctly into the DD file, but the LHS (written in uppercase in the template) is written in lower case there. Why is it in lower case?  Surely it should be in upper case, as it is correctly so in the UC_NCAP written in the same DD file.

[AKanudia]

Dear Antti,

Thanks for flagging this. With the current way of storing this information, Item Details view would be the natural place to show this. Would that be OK?

GAMS is not case-sensitive and ACCESS isn't either. Consequently, Veda models have been case-insensitive. But PostgreSQL is case-sensitive. Dealing with this without taking a performance hit has been a challenge for us. To simplify things, we have imposed lower case in some cases where the list of elements is not under user control, like SIDE.

If you have a strong preference for the case to be respected here, then please let us know.

[Antti-L]

Thanks Amit. 

Seeing it in item details would be fine.  But why not also in Browse; it was shown there in the old VEDA.

Concerning the casing, now I am getting uppercase in the DD file if I am not specifying it, and lowercase if I specify it in upper case.  It looks illogical and confusing.

Anyway, Side is a system set in TIMES.  LHS and RHS are acronyms (for Left Hand Side, Right Hand Side) and so I think they should obviously be in upper case.

[AKanudia]

OK, we will do the best we can in the next update.

[Antti-L]

Indeed, I can see the case sensitivity of PostgreSQL may pose some problems.

When I use two columns, UC_ATTR~LHS and UC_ATTR, I get two entries in the DD file (and thus a GAMS error):

SET UC_ATTR
/
'REG1'.'UC_MaxInvSub_REN_MoFo'.'lhs'.'NCAP'.'SUB'
'REG1'.'UC_MaxInvSub_REN_MoFo'.'LHS'.'NCAP'.'SUB'

/

Does this imply that under VEDA2 the user must make sure that she writes all labels using the same casing?  I mean, does e.g. update / migrate work correctly if TFM_UPD / TFM_MIG happens to use different casing than the source scenario?  If they don't work any longer, that would be an issue...  then I think this problem would indeed deserve some more consideration.

[AKanudia]

Thanks for creating this case. We will certainly take care of this.

Veda handles the case in all string comparison operations.

[Antti-L]

Thanks Amit!

BTW: I just found information on the net about the citext character string type in PostgreSQL.

"The citext module provides a case-insensitive character string type, citext. Essentially, it internally calls lower when comparing values. Otherwise, it behaves almost exactly like text."

It seems to have a number of advantages, e.g.

  • you don't need to convert case in queries
  • queries will utilize indexes, which they would not if you would use lower()

The citext data type thus allows you to eliminate calls to lower() in SQL queries, and allows a primary key to be case-insensitive. And it is locale-aware., too.

That sounds good to me.  Maybe you are already using citext in VEDA2?