Thanks Robert! And there's another one!
- $LISTBUILD – Builds a list from elements or extracts elements from a list.
- Log in to post comments
Thanks Robert! And there's another one!
I have a comment on the sentence "I don't want to use Xecute because I am in need of really high performance code."
I have always thought of Xecute and @ (indirection) as similar in performance characteristics. But I don't know what the current reality is. Is it possible that omer was told that Xecute is slow and indirection wasn't mentioned?
Here are some quotes from the docs. I don't see anything here that indicates Xecute is slower or faster than indirection. Maybe someone else on this thread has more detailed knowledge on the difference if any.
I didn't even think to check if other %variables were handled automatically. I will add the request for %sqlcontext right away.
Common Table Expressions are now supported starting with v2024.1: https://docs.intersystems.com/irisforhealth20241/csp/docbook/DocBook.UI…;
$increment is (or used to be) unique in that it was the only function that changed its argument. It reminded me of learning about "destructive functions" in LISP a long time ago. No matter where/how you use it, it increments. So "set a = $increment(a)" is redundant, but still OK to use. As you saw, developers started to use "if $increment(a)" alone, because that was shorter but also works fine, even thought it looks strange. I wasn't aware of "do $increment(a)" being allowed, which does look nicer, so I also learned something new from this thread, thanks.
And let's not forget to mention the popular and useful "set a($increment(a)) = something"
I never encountered this issue. I assume it's because AutoSave is off by default, and Steve and others that have commented turned it on. I noticed that there IS a setting called "Auto Save When No Errors."
Very nice. Please remove "not" from "...its associated searches does not open up a world of opportunities..."
Steve, I've conveyed your message about Class Queries since the first time you mentioned it to me, oh so long ago. However, if you wanted to use Class Queries for Tim's example, you'd have to write 17 different queries, and call the right one based on the input you got. Every feature has its uses.
Oh, and one more little tidbit about the 2nd argument to %ExecDirect(), the one containing the SQL text. Instead of being a single long string, it can be an array of strings, passed by reference with a leading dot (not variadic). So the first few lines of GetTransactions() could look like the example below. This approach has the nice benefit of adding spaces between each line; notice I removed the extra spaces at the end of each line of SQL.
set sql = 1
set sql(1) = "select Product->Name, Outlet->City, AmountOfSale, UnitsSold "_
"from HoleFoods.SalesTransaction where Actual = 1"
if (product '= "") {
set sql($increment(sql)) = "and Product = ?"
set args($increment(args)) = product
}
if (channel '= "") {
set sql($increment(sql)) = "and Channel %INLIST ?"
set args($increment(args)) = channel
// ...and so on...and eventually...
set result = ##class(%SQL.Statement).%ExecDirect(, .sql, args...)It's a leading dot and trailing dots festival.
A few thoughts on this lovely post:
Some more thoughts on this:
I edited this post and made some corrections below.
I think the Community needs more information in order to help you. Data for %Persistent classes is stored in globals. Data for %SerialObject classes is also stored in globals. Properties of %Persistent classes can reference %SerialObject classes, and when the %Persistent data is saved, the referenced %SerialObject data is also stored in globals.
The decision about whether to create %Persistent or %SerialObject classes for storing data is an object modeling decision, unrelated to the need to purge data on some schedule. Changing classes from %Persistent to %SerialObject (or vice versa) for an existing application is a major design change which would probably require plenty of code rewrites. I don't think anyone would do that work just for the sake of purging. There must be something else going on.
Semi-educated guess: Maybe when you say "purging" you're talking about purging messages in interoperability productions. These messages have message headers, message bodies, and the bodies may have properties that reference %Persistent or %SerialObject objects. When you purge those messages, you have the option to purge message bodies, but if the bodies reference %Persistent objects, the referenced objects are not purged. Maybe that's what you're seeing, and maybe that's why you're thinking of switching storage definitions. There is certainly a way to make sure that any referenced objects get purged when messages are purged, documented (briefly) here. The WRC can also offer assistance.
Please tell us if my semi-educated guess is correct, or if not, please give us more information. Happy New Year!
Very interesting question! In case anyone is wondering, in Studio you can access this info in the Workspace View on the Namespace tab or the Project tab. Right-click on the package name, and click Package Information. The information entered here is stored in the ^oddPKG global, subscripted by package name.
There doesn't appear to be a way to access this information in VS Code. I think it's worth creating an issue for this here (VS Code ObjectScript issues) and see what happens.
I'm not exactly sure what fast shutdown is so I don't know the answer. I'm also not sure if "iris force" is the same as fast shutdown. I suppose they could be similar. When you do "iris force" IRIS runs an irisstat to capture the pre-force state and writes it to messages.log; fast shutdown doesn't do that.
Edit: I also learned that fast shutdown waits for our system daemons to quiesce whereas iris force doesn't wait. @Eduard Lebedyuk: despite that behavior, maybe iris force takes longer because it runs irisstat.
It is ideal to stop IRIS before stopping the OS. However, if you stop the OS while IRIS is still running, IRIS can handle it. Check the IRIS messages.log after you shut down the OS, and you'll see lines like these:
10/16/23-18:11:04.649 (5940) 1 [Generic.Event] Operating System shutdown! InterSystems IRIS performing fast shutdown. 10/16/23-18:11:06.001 (5940) 1 [Generic.Event] Fast shutdown complete
If your plan is to stop the OS and change the machine name, then definitely shut down IRIS in advance of stopping the OS.
I think it's really important that you find out why the tool is written to start a transaction before every query.
The three techniques for using SQL in your code (Class queries, Dynamic SQL, Embedded SQL) each have their pros and cons. The %ObjectSelectMode and tResult.<column> (instead of tResult.%Get("<column>") ) features only work with Dynamic SQL.
Thanks Mihoko!
Also note: the argument with ... after its name doesn't have to be the only argument to the method; it must be the last argument to the method. So NewMethod1()'s signature could be:
ClassMethod NewMethod1(a as %String, b as %String, c... as %String)
{
kill ^a, ^b, ^c
set ^a = a, ^b = b
merge ^c = c
}Running it like this:
USER>DO ##class(TEST.ARGTEST1).NewMethod1(1,2,3,4,5,6,7) USER>ZWRITE ^a, ^b, ^c ^a=1 ^b=2 ^c=5 ^c(1)=3 ^c(2)=4 ^c(3)=5 ^c(4)=6 ^c(5)=7
So...if Person #1 in the above example references demo.intersystems.Car #54, the "Dan P big secretly loaded" copy of that Person object also references the same Car #54, right? @Timothy Leavitt, is that good or bad for your use case? Doesn't %ConstructClone(1) give you what you need? If not, where does it fall short?
Does this example make it clear? Does this meet your needs?
USER>set human = ##class(Simple.Human).%OpenId(1)
USER>zw human
human=20@Simple.Human ; <OREF>
+----------------- general information ---------------
| oref value: 20
| class name: Simple.Human
| %%OID: $lb("1","Simple.Human")
| reference count: 2
+----------------- attribute values ------------------
| %Concurrency = 1 <Set>
| Company = "GlobaDyne Inc."
| Name = "Smith,John"
| Phone = "265-288-5681"
| Version = 2
+----------------- swizzled references ---------------
| i%Home = $lb("6489 Clinton Street","Denver","NJ",26882) <Set>
| r%Home = "" <Set>
| i%Work = $lb("9353 Main Drive","Hialeah","MI",72997) <Set>
| r%Work = "" <Set>
+-----------------------------------------------------
USER>write human.%IsModified()
0
USER>write human.PhoneIsModified()
0
USER>set human.Phone = "111-222-3333"
USER>write human.%IsModified()
1
USER>write human.PhoneIsModified()
1
USER>write human.Home.Street
6489 Clinton Street
USER>write human.Home.StreetIsModified()
0
USER>set human.Home.Street = "111 High Street"
USER>write human.Home.StreetIsModified()
1
USER>I think it would be great if you would explain the use case to the community.
After reading through this thread, it seems like there are two questions:
Would it be possible for you to share your reason for wanting to do this with the community?
%Library.ResultSet (aka %ResultSet) is deprecated. You should switch to using %SQL.Statement instead. It's better in every way. Doc is here: Dynamic SQL and within that there's a section on Metadata.
Anything can be achieved without instance methods. The point here is that instance methods exist in object-oriented systems because they are considered a good, straightforward way to achieve certain things. In the case of unit tests sharing information using properties, that approach saves you from having to pass info around as method arguments, or declaring a list of public variables.
I've also used Studio for 20+ years. I can still remember how much better it was than what we had before. We can all still use Studio if we want; it's not a forced divorce. But we hope that VS Code -- ObjectScript's features will make you comfortable enough to decide to do a conscious uncoupling. And as Frank Sinatra sang: "Love's much lovelier, the second time around." And he could have sung that at the Diplomat Hotel in Fort Lauderdale in 1974, where coincidentally InterSystems is hosting our Global Summit this year!
In the interest of accuracy, Studio does allow looking at OREFS to see their properties (View As > Object, or Dump object).
Why are unit test methods instance methods? Since a running unit test is an instantiated object (%RegisteredObject), the unit test class itself can have custom properties, and the instance methods can use those properties as a way to share information. For example, initialize the properties in %OnBeforeAllTests(), and then access/change the properties in the test methods.