This (getFiles) method is marked as internal in Cache, and yes, it's typical internal as it's usage is relied on the strong internals knowledge :). Besides, it's hidden in IRIS, and its caller should be rewritten to achieve DBMS independence:
ClassMethod ListDir2(path = "", wildchar = "*", recursive As %String(VALUELIST=",y,n") = "y", ByRef dirlist)
{
s pExtension=1
s pExtension(1)=wildchar
#if $zversion["IRIS"
s temp=$name(^IRIS.Temp)
#else
s temp=$name(^CacheTemp)
#endif
s pTempNode=$i(@temp)
k @temp@(pTempNode)
d ##class(%SQL.Util.Import).getFiles(path,.pExtension,pTempNode,recursive="y")
m dirlist=@temp@(pTempNode)
k @temp@(pTempNode) ;zw dirlist
}
your initial question should be reformulated as "how to find global's [main] database" because all namespaces have "equal rights" for any global which is visible from (= mapped to) them.
Julias is quite correct in his answering, but you should take into account that it concerns the global's main database only. If global subscript mapping is used, the full solution to get the list of all databases where the global is partially mapped is a more tricky task. If somebody is interested, I can write about how I solved it once.
What about the second pass with the same ObjectScript code w/o restarting IRIS? 1.7GB is not too much to be stored in the file system cache, so it should be ~5 times quicker. Besides, it's well-known that Cache (IRIS) as a record readeris not so good as a block reader. Everybody knows that %GIF is 5-10 times quicker than %GI. I have the same experience with my own developments: processing files at the block level (read block#$$$BLOCKSIZE) with records parsing at the COS level is quicker than read it record by record. `5*5=25` is close to the time difference between your ObjectScript and Python code runs.
I've written this just to emphasize that we should love Python mostly for the power of its ecosystem, as Nigel wrote. As to speed, it would be better if you InterSystems guys do something to improve file i/o record level operations in IRIS engine...
Meanwhile, I was definitely logged in at InterSystems sites. I've already have checked it up in two different browsers with the same result. Not a great problem for me, just to inform the community team.
if there will be an error this won't change the namespace back even with the "new $namespace" command
It would be still "%SYS" inside the `catch` block, so it's unsafe to call any code in its context. Even if you write something like this:
...
try {
new $namespace
set $namespace="%SYS"
...
} catch ex { // process the error
set sc=ex.AsStatus()
do ..logErr(sc) // do some debug logging
}
return sc
and the ..logErr() call will be successful (generated .int code was not split into parts), the global where the log goes should be the same for all namespaces (e.g. mapped via %ALL pseudo-namespace). There are so many complications that it seems better to avoid any error processing inside the `catch` block above returning the error code. BTW, it sounds reasonable in any case, not only in this one associated with %SYS.
It would change. I mean that try/catch is still needed to handle exceptions that can occur during namespace change or after the change, working in "%SYS" (mostly security violation errors). Otherwise the method can produce unsolicited exceptions.
go to post
@Tony Alexander,
your method is ~30% faster then "ready made" on the directory tree populated with ~ 200 files.
Keep re-inventing wheels!
go to post
This (getFiles) method is marked as internal in Cache, and yes, it's typical internal as it's usage is relied on the strong internals knowledge :). Besides, it's hidden in IRIS, and its caller should be rewritten to achieve DBMS independence:
go to post
Hi Yuri,
What do you mean by IoC?
1) Indicator of Compromise, IoC
or
2) Inversion of Control
go to post
That approach works only for *.INT routines. Don't you use *.MAC and *.INC as well?
go to post
Bharathsimha,
your initial question should be reformulated as "how to find global's [main] database" because all namespaces have "equal rights" for any global which is visible from (= mapped to) them.
Julias is quite correct in his answering, but you should take into account that it concerns the global's main database only. If global subscript mapping is used, the full solution to get the list of all databases where the global is partially mapped is a more tricky task. If somebody is interested, I can write about how I solved it once.
go to post
What about the second pass with the same ObjectScript code w/o restarting IRIS? 1.7GB is not too much to be stored in the file system cache, so it should be ~5 times quicker. Besides, it's well-known that Cache (IRIS) as a record reader is not so good as a block reader. Everybody knows that %GIF is 5-10 times quicker than %GI. I have the same experience with my own developments: processing files at the block level (read block#$$$BLOCKSIZE) with records parsing at the COS level is quicker than read it record by record. `5*5=25` is close to the time difference between your ObjectScript and Python code runs.
I've written this just to emphasize that we should love Python mostly for the power of its ecosystem, as Nigel wrote. As to speed, it would be better if you InterSystems guys do something to improve file i/o record level operations in IRIS engine...
go to post
Hi Olga,
Thanks, it's working now.
go to post
Hello Olga,
I'm getting from Global Masters:
https://login.intersystems.com/oauth2...
----> Unexpected request - invalid_request
Meanwhile, I was definitely logged in at InterSystems sites.
I've already have checked it up in two different browsers with the same result. Not a great problem for me, just to inform the community team.
go to post
It would be still "%SYS" inside the `catch` block, so it's unsafe to call any code in its context. Even if you write something like this:
and the ..logErr() call will be successful (generated .int code was not split into parts), the global where the log goes should be the same for all namespaces (e.g. mapped via %ALL pseudo-namespace). There are so many complications that it seems better to avoid any error processing inside the `catch` block above returning the error code. BTW, it sounds reasonable in any case, not only in this one associated with %SYS.
go to post
It would change. I mean that try/catch is still needed to handle exceptions that can occur during namespace change or after the change, working in "%SYS" (mostly security violation errors). Otherwise the method can produce unsolicited exceptions.