If upgrading is on the cards, our recent IRIS 2021.2 release has built-in connectors for S3 and more
- Log in to post comments
If upgrading is on the cards, our recent IRIS 2021.2 release has built-in connectors for S3 and more
This is indeed a new piece of ALTER TABLE syntax we introduced between 2020.1 and 2021.1, so nothing wrong with your 2020.1 instance
Can you be more specific about what you mean with "can't be deleted"? If this is a <PROTECT> error because they are mapped to ENSLIB (as part of enabling the namespace for Interop as Robert described), you can just ignore that error in a try / catch block.
I'm not sure about the general application context but if you need to go through the full list of globals for your app, it may be be better to query the globals that are in your application's database (directory) using %SYS.GlobalQuery:DirectoryList() rather than all the ones that are visible in the namespace using %SYS.GlobalQuery:NamespaceList() or ^$GLOBAL. That'll avoid the issues with ^EnsEDI.
Note that if you are actually using DeepSee or interop (or more generally rely on any features that may be writing their own globals), just looping through the global list for this kind of operations is very risky. Most built-in IRIS features (besides DeepSee and interop, that is) will write to globals prefixed with ^IRIS.*
hang on there. What I said on discord is only that the DDL nature of this command prevents it from supporting query parameters. We are looking into expression support inside the VALUES clause. You still have time to stress the importance of this in the survey ;-)
woops, I got that quite wrong indeed. I got confused by the mentions of TSQL earlier in the thread and mistook it for some other lock-related syntax that's only there for TSQL. you are correct: LOCK TABLE is part of IRIS SQL.
I'm not sure whether the error message you got would have further clues, but likely you're better off filing this with the WRC. Given that it works for embedded SQL, I'm suspicious it may have to do with the pre-parser for .NET, which does an initial parsing of the command on the client side.
Did you set the SQL dialect to MSSQL or Sybase? That LOCK TABLE command is not part of IRIS SQL. I'm not familiar with .NET myself, but found this older code sample (rename to IRISConnection()):
_tconn = new CacheConnection(connectionString);
_tconn.SQLDialect = "MSSQL";
_tconn.Open();thanks for contributing this @Andreas Schneider! Your testing and feedback will help us build a better product, and we'll likely get most of this out of the way before 2021.2 goes GA
Thanks @Kevin Chan for helping out (he's the author of the parser piece of LOAD DATA ;-) )
In addition to his comments on the encoding issues, you can also take a look at the %SQL_Diag.Result table which will likely have more detailed error info than what we're able to return through SQL semantics (though we're still working on ways to make it clearer). There's also a %SQL_Diag.Message table with row-level errors, which can help you figure out the reason for individual row failures.
Congratulations!
We're lucky to have airpods as the third place prize. Those were easy to split equally between the tied contestants :-)
This sounds exciting! Do you have a demo video, screenshots or a link to the full product page to make it more tangible?
Correct. We can only use this for classes using %Storage.Persistent (and %Storage.Shard), because of the wildly varying structures (not least involving multiple globals) you might project using alternative models.
Here are two examples using Synthea:
And two example repositories using LOAD DATA (but not yet ZPM-enabled):
See also this DC article about the subject.
What exactly do you want to "switch back" and why?
an iFind transformation would be helpful if you would sometimes want to query the non-transformed form as well, which I don't think is the case here. Just a computed field and/or @Timothy Leavitt s excellent BuildValueArray() sample would be a simple and effective solution.
Of course it's just one approach to the problem but I hope it can be helpful.
Stay tuned for a dedicated LOAD DATA command in IRIS SQL coming very soon :-)
The iFind search portal demo includes a simple class query to find similar documents within a single iFind index. It's only pretty basic and somewhat picky (assuming the demo setup), building on the dominance score for each entity, and may not guard against that difference in length issue you're seeing with BM25. There is a similar method in iKnow when your data would already be in an iKnow domain.
There would indeed be value in providing %SIMILARITY support for iFind indexed fields, leveraging the standard/enhanced algorithm on top of word tokens. I'll log that as an enhancement request and we can follow up internally. Obviously, I'm interested in experiences or advice of other DC members here
yes, they are the same. Like Studio and ODBC, it's an install-time option to right-size your footprint (and therefore highly relevant for container images). I'm not sure if there's a handy utility method to check if it's been installed or not, but @Thomas Dyar would know.
eh, it's the sixth item in the list?
Yes. If you navigate to the WRC software distribution site or even just https://download.intersystems.com/, you can select community edition kits for a variety of platforms, including Windows.
You're spot on. The similarity between Python and ObjectScript plus its popularity (Python's, that is ;-) ) are exactly what drove us to build Embedded Python. We're not compiling it to .obj code though, but running it "as Python" in the kernel. @Bob Kuszewski and @David McCaldon are much better at explaining that nuance (and actually do in the intro webinar to our early access program for this upcoming feature.
Hi Nigel,
glad you like the Python Gateway work. Perhaps you're also interested in participating in the embedded python EAP?
As for APL, we're typically looking for some critical mass of customer demand before embarking on such a development project and only recall it being mentioned once before. But thanks for bringing it up, as each critical mass starts somewhere :-).
This said, we've had some really great work pioneered in the community here. The Python Gateway project is one example that originated here and its popularity (thanks @Eduard Lebedyuk and @Sergey Lukyanchikov
!) inspired the one now released as part of the core InterSystems IRIS platform. Similar concepts, such as the Julia Gateway are still "incubating" as a community-driven project. Maybe APL could fit that same path?
I believe the R one goes through the Java gateway, but not sure why it's not described (yet) in the docs. Pinging @Bob Kuszewski for more detail
Yes to both questions: For a full list of the available images, please refer to the ICR documentation.
Our doc team is updating that page today, but generally anything for which there was a 2021.1.0.205.0 tag, there should also be a 2021.1.0.215.0. There were a few open questions on the new permutations that we were looking through this morning.
Thanks for bringing it up. This had already been fixed in our working branch, but the fact that the port to 2021.1 was missing unfortunately escaped our automated tests. The fix will obviously be in the GA release, but we might publish another preview build before then to pick up this fix.
not anymore. As of 2021.1, it's part of the main kit (aka "mainstream availability of IntegratedML" in the announcement above
)
No. Any and all new features are going into IRIS.
Thanks for prodding me on this. It's a perfect opportunity to advertise an upcoming feature that addresses this exact problem.
SQL collations have existed for a long while, but as Robert pointed out, were restricted to playing with upper/lower case, truncation, whitespace and the odd numeric ploy through a limited set of built-in collations. Later this year, we'll release a more generic %COLLATE() option that allows you to combine these properties any way you like, including a translation that removes all accents (both as a SQL collation option and a new $zconvert() option).
In the meantime, you can use the somewhat impractical workarounds described above, or possibly use an iFind index and specify a TRANSFORMATIONSPEC that removes the accents.