Hi JD,

I am able to reproduce this problem. I am looking into it and I will update here when I have more information.

The IRIS for Health Community Edition listing on AWS is scheduled to updated this week with the 2019.2 version. If this is a bug it will be fixed in the update. 

Thanks,

Joe

There are some changes coming in the near future to the default logging behavior of the IRIS container . The goal is improve the usefulness of what is written to standard out by default. Of course, if you need to customize (or want to turn it off) --log is there for you, but soon you will not need to manually specify messages.log as it will be there by default (Durable %SYS or not, whichever one is active). The current syntax you have, and what Conor suggests, will work moving forward, but with an upcoming release (under wraps) it will become unnecessary.

Hi Evgeni,

This is a known problem with our the IRIS 2018.2 Preview Community Edition listing which is under active development. We are in the process of correcting this, but it will take some time. When it is fixed you will have to redeploy the listing to pick up the changes. 

Since you have been directed to this listing, I assume, by an InterSystems contact the best way to get you up and running is to contact them (and me) directly through email so that we can get you set up with an evaluation key.  This is a conversation which should take place outside of this Developer Community post. My email address is Joe<dot>Carroll@InterSystems.com

Although Atelier will not work with this listing, yet, the non-atelier portions of the Quick Start experiences  as well as those hosted by InterSystems Online Learning will work. These can be found here. 

https://learning.intersystems.com/course/view.php?id=1055&ssoPass=1

Thanks,

Joe Carroll

Everyday I read legacy code like this, but if we're talking about the ideal (like coding guidelines) we want to avoid these. I agree that every Object Script developer should be able to read this code, but they should also know that there are better modern ways to write this. 

I think that part of growing the community of Object Script developers is to lower barriers to entry. Having worked with a lot of new Object Script developers (and been one myself), one of the largest barriers to entry is the prevalence of cryptic legacy syntax in existing code. 

Remember, just because we can read it doesn't mean that everyone can.

We want our code to be as accessible and readable as possible to as many people as possible. We always prefer whitespace formatting and curly brackets to arcane one line syntax. Someone who's not an Object Script expert will know what this does -

if a { 
   set b=a 
}

But there's no guarantee that a novice will necessarily know what these do -

if a set b=a
set:a b=a

Good code is readable and clever one liners will get in the way of that goal.

Whoops! I forgot a word. Its supposed to say "Embedded SQL is a tool that allows us to  execute SQL statements in Caché Object Script." I will fix it. Thanks

 

:)

The %vid is something that you're going to need to specifically select even when using *. This is documented here - but it seems that this is the documentation you're quoting already :)

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

I'm a little confused about what you mean when you say,

"He is confused that select %vid from (select ...) returns dummy number whilst select *,%vid from (select...) returns correct data."

Running this query might help clarify,

select Id, name, %vid From (select top 10 * from Sample.Person order by name) where %vid BETWEEN 5 and 10

The %vid is not a dummy number - in this case it is essentially to the row ID of the result that we're selecting from. In this case, it represents the integer ranking of the records alphabetized by name, but it really depends on the query. This is not the ID of the person records themselves.  

You don't necessarily need to do a "select *,%vid...", but most likely you want to select some other columns from the view besides %vid.

Does this help?

Thanks Kyle!

 

Just for clarity, here's a little more context regarding the Identity keyword and the IdKey keyword. Specifically, regarding what other effects these might have on your table/class design.

 

Identity 

  • Like the Highlander, there can only be one property marked [Identity], otherwise you will get a compile error. This is pretty intuitive, but the reason for this is that the property is being mapped to an "identity column" (really, SQL IDENTITY) in the SQL table. 
  • Identity properties MUST be of type %Integer. 

IdKey

  • This keyword specifies that the property(ies) that we're using to build this index  will be combined to form the "Object Identity" value for the instance of the object in question.
    • The "Object Identity" value is what use to locate and uniquely identify persistent objects.
    • As a result, if there is an IdKey index built using certain properties, you CANNOT modify the values of those properties after you have saved the object (or inserted the row).
  • "IdKey" indexes are "Unique". That is, it is redundant (but allowed) to have an index tagged as both Unique and IdKey
  • It is not recommended to have "||" (sequential double pipes) in the properties that are used to build the IdKey index. This will result in unpredictable behavior. 
    • This is an artifact of how Caché SQL engine works.
    • The exception, of course, is if that property is a valid reference to a persistent class.