All
Accepted answers
Gertjan Klein · Nov 10, 2019 go to post

This should have been the accepted answer. :) It is more important for code to be easy to read than for it to be easy to write.

Gertjan Klein · Oct 29, 2019 go to post

I have enabled and used that feature in older versions as well; it is really useful. I have a PuTTY setup with a key pair that starts the IRIS terminal in docker on a remote machine, without any password, but still safe. (I wanted to use my regular account name as well, so I had to do some additional setup in the container, but the principle remains the same.)

Anyway, that explains why there's no need for a password anymore, thanks!

By the way, I have not een an announcement that 2019.3 became an official release, did I miss something? (I also see no Studio for 2019.3, and the 2019.4 preview Studio download doesn't work.)

Gertjan Klein · Oct 28, 2019 go to post

Thanks for that, Evgeny, that does clear up things a bit. I hope Luca responds as well about the Quiesce... and SetMonitorState calls. I get the impression that things relating to creating containers are still changing rapidly. I do find the backslash-escaped multiline commands annoyingly ugly; your post above made that a bit better, compared to what was there before. (I'm hoping some of the ugly boilerplate will be delt with by ISC "inside" the container eventually.) I'm going to play around with your template a bit when I get the time!

Gertjan Klein · Oct 27, 2019 go to post

This looks like a convenient way to handle things. It would be good, though, if someone could explain what the various ObjectScript commands in irissession.sh are needed for. I also see no credentials being passed?

Gertjan Klein · Jun 3, 2019 go to post

That link works. But if I search with Google (or DuckDuckGo), the first link that comes up for me appears to point to the proper page, but opening it loads a page about  SOAP Session Management. Many other links from Google end up on that page as well. The key in the docbook URL is ITECHREF_macro, that looks ok, so it seems the ISC docs are broken somehow.

Gertjan Klein · Feb 22, 2019 go to post

If you massage the timestamp format a bit so it is ISO8601/XSD compatible, you can use the XSDToLogical method of %TimeStamp to do the conversion for you:

DEV>Set ts = "2018-02-01 00:00:00+0600"
DEV>Set ts = $Translate(ts, " ", "T")
DEV>Set ts = $Extract(ts, 1, *-2)_":"_$Extract(ts, *-1, *)
DEV>Write ts
2018-02-01T00:00:00+06:00
DEV>Write ##class(%TimeStamp).XSDToLogical(ts)
2018-01-31 18:00:00

Gertjan Klein · Apr 24, 2018 go to post

I have not run into this problem. Also, it appears that Caché already adds the Content-Length header:

  Set req = ##class(%Net.HttpRequest).%New()
  Set req.Server = "www.google.com"
  Do req.EntityBody.Write("test")
  Do req.Put("/", 1)

Yields:

PUT / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; Cache;)
Host: www.google.com
Accept-Encoding: gzip
Content-Length: 4
Content-Type: text/html; charset=UTF-8
test
 

I suspect Content-Length isn't the actual issue. I don't have any ideas about what is, though. (Perhaps you should at least check if your Caché sends it.)

Gertjan Klein · Apr 16, 2018 go to post

This datatype is not present in (currently latest) Caché 2017.2; it appears to be IRIS-only. That rather limits its usefullness. Besides, what is the performance of a datatype, and where is that a bottleneck?

Gertjan Klein · Jan 4, 2018 go to post

The error message tells you what the problem is. It claims there is no end tag for CardType. If you look closely, you'll see that there is a space between "</" and "CardType>". Remove that, and the message will parse correctly. (Kudos for giving complete information and copy/pasting instead of retyping!)

Gertjan Klein · Nov 22, 2017 go to post

If you add a property with an XMLPROJECTION set to CONTENT, it should be output without the wrapping tags. E.g.:

Property content As %String(XMLPROJECTION = "CONTENT");

Regards,
Gertjan.

Gertjan Klein · Aug 17, 2017 go to post

It appears to be enabled when I try here, but I haven't used recordmaps much so I don't have one fully configured. I see another setting for the encoding in the record map properties itself; perhaps this is where things should be configured? (That would also explain why the adapter setting is disabled: you want to configure this only once.)

Gertjan Klein · Aug 17, 2017 go to post

One of the settings for this service (category Additional settings) is Charset. This allows you to specify the file charset. Did you try setting this to UTF-8?

Gertjan Klein · Aug 10, 2017 go to post

Unfortunately, long strings can't be 3GB, but rather almost 3.5MB. For any sane usage of JSON this should be enough, but I've seen REST APIs where e.g. PDF streams are returned in base64-encoded JSON properties, that come uncomfortably close to that size.

It would be really nice if the %DynamicObject class added support for streams to deal with these large payloads!