go to post Benjamin De Boe · Jan 27, 2023 %SYS.Audit already projects to each namespace, but the data is in a privileged database and requires %Admin_Secure:USE privileges, so better not try to circumvent / confuse that through mappings. I would not create additional temp tables or mappings to try and cling to SQL as that is meant to run in a single namespace as a query language. This sounds more like a procedural thing for ObjectScript, so a stored procedure that loops through the Production namespaces, retrieves all config items in a local variable and then uses that for querying the audit table after switching to %SYS sounds more appropriate. Rather than a PPG, I'd just collect it in the qHandle local variable passed between Execute() and Fetch() methods for your custom query, unless it risks getting too big
go to post Benjamin De Boe · Jan 16, 2023 Hi @Michael Hill, I'm still not sure I understand how your % variable is meant to be used. Can you make this more concrete? Thanks,benjamin
go to post Benjamin De Boe · Jan 13, 2023 Can you provide a little more context on what your subqueries are trying to accomplish? Conceptually, it feels a little unnatural to force PID awareness into SQL (sub)queries, so maybe this is more an application scenario asking for more direct interaction with the Work Queue Manager. In 2022.2, we introduced an Application Metadata Stack that SQL (and in the future other subsystems or application code) uses to stash a little context in the process metadata in order to build things like the SQL Process View. Amongst other things, that metadata helps us tie subquery processes to their parent. Right now we have no public API to interpret this rather technical metadata directly from the stack, but maybe you can convince us there's a use case :-)
go to post Benjamin De Boe · Jan 10, 2023 Nice visionary article! Luckily we didn't rush this 13 years ago ;-) as the model described in there would offer some benefits, but not get to the order of magnitude performance improvement we're bringing with this new IRIS feature. Organizing data in separate nodes as proposed there may help somewhat to limit the size of each read (read the column value rather than the full row's $list), but you're still doing NxM small grefs to read M columns for N rows. When you're talking billions of rows, that sheer volume of grefs is the bottleneck we saw preventing us from doing really well on analytics queries. With Columnar Storage, the new $vector datatype we introduced that encodes 64k values into a single global node offers much better economies on today's hardware, and also enable SIMD instructions on those, which you couldn't get by keeping values in separate variables. Of course introducing all-new datatypes (and especially internal ones like $vector) isn't something you could do using ObjectScript in user code, but I promise we'll offer Key-Value before IRIS 2036.1! :-)
go to post Benjamin De Boe · Jan 9, 2023 Nice work! Very convenient to have this all laid out in such detail
go to post Benjamin De Boe · Dec 27, 2022 They're on the WRC preview distribution page and I see enterprise edition ARM64 containers on ICR after logging in. We'll check why the CE containers are not (yet) on ICR for this build.
go to post Benjamin De Boe · Nov 10, 2022 FWIW, Abstract classes inheriting from %Persistent (or even %SerialObject) do have a storage definition and can define indices too. They just can't be instantiated. To prevent the creation of a storage definition, NoExtent is the keyword to use.
go to post Benjamin De Boe · Nov 10, 2022 For the record: it's not the Abstract-ness that leads to the index being ignored, it's the fact that the index is not defined in the primary superclass of Test.NewClass1. From secondary superclasses, only parameters, properties and methods are inherited, but not indices. So you can keep Test.NewClass Abstract, but make it inherit from %Persistent itself and then have Test.NewClass1 point to it as its primary superclass. I'll ask the doc team to make this a little clearer, as it's not obvious from this section of the doc nor the one on indices right now. This said, @Robert Cemper 's suggested use of NoExtent is likely what you wanted to achieve.
go to post Benjamin De Boe · Nov 10, 2022 Yes, it always behaved like this. Currently, table stats are stored as part of the class definition, based on the idea that they are often kind of static and belong with the application. That holds for certain types of applications, but in many cases it is a little too static and this is especially true for the Message Bank example here, as TuneTable cannot update class definitions for a read-only system class. We have a project coming up to move the table stats to live with the data rather than keep them in the class definition and hope to bring that to an IRIS release in the course of 2023. In the meantime, the workaround suggested above, marking ENSLIB as writable, running TT and then marking it read-only again is reasonable (though quite a step from an official recommendation). Note that after upgrades, your ENSLIB will be overwritten and your stats will have been lost. FYI, the last part of this article also touches on this subject
go to post Benjamin De Boe · Nov 7, 2022 In the case of JDBC, there's also the getGeneratedKeys() method that you may find useful. We're looking into support for a RETURNING clause for the INSERT command as a possible enhancement (Postgres' flavour of this nonstandard clause is very nice), but don't hold your breath as we have a long list of such candidate enhancements and a much shorter list of people who can work on the surprising amount of places in our codebase that would need to be updated to accommodate such a syntax extension.
go to post Benjamin De Boe · Oct 30, 2022 There is apparently an internal-design-level distinction between UDL as an editor format and XML as an export format. We appear to have closed the case without clarifying the documentation on this point (apologies for this oversight), but I've reopened the case so we might review and reconsider the current behaviour more broadly. There's a number of additional flags like these, so it's possibly a larger change.
go to post Benjamin De Boe · Oct 27, 2022 @Vitaliy Serdtsev is right in pointing to the resultset's metadata. That's where IRIS SQL registers column datatypes and he already pointed out that this is obviously not impacted by the presence of an ORDER BY. The resultset object returns the SQL-side value to ObjectScript, but on that ObjectScript side, the datatype no longer matters as it isn't strongly typed and still 1="1". Therefore, I don't think this constitutes an error. FWIW, the reason you're seeing this is that due to the ORDER BY clause we're picking up that id value from the index' subscript rather than from the master map.
go to post Benjamin De Boe · Oct 17, 2022 Try the zremove (or zr in short) command without arguments.
go to post Benjamin De Boe · Oct 17, 2022 Unfortunately we're not able to offer transactions across linked tables. For one thing, the remote database may use different transaction semantics. I will request this gets clarified in our documentation, as it's not called out right now as a limitation of linked tables.
go to post Benjamin De Boe · Aug 30, 2022 Hi Jun, those sandboxes are controlled environments set up for specific courses. There isn't really a course corresponding to this demo / subject, so unfortunately no single-click-install this time. Once you have a running instance of IRIS, setting it up through the commands described above shouldn't be that big a deal: do $system.OBJ.ImportDir("/path/to/downloaded/isc-iknow-setanalysis","*.xml","c",,1) do ##class(Demo.SetAnalysis.Utils).CreateRestWebApp()
go to post Benjamin De Boe · Aug 22, 2022 Thanks @Vitaliy Serdtsev Indeed, that method will be deprecated shortly, in favour of CREATE TABLE AS SELECT, which is new in 2021.1 and part of the SQL standard. Both this command and the $SYSTEM utility method will create a physical copy of the data, so a real SQL table that's not kept in sync in the way a SQL view is. If the latter is what you need, don't bother with creating it as a table. Note that in a more recent version we also support the CREATE OR REPLACE syntax for a bunch of additional statements (including CREATE FUNCTION, CREATE PROCEDURE, ...) and CREATE IF NOT EXISTS for things that actually contain data such as tables.
go to post Benjamin De Boe · Aug 22, 2022 I'm not sure I understand which sandbox you're referring to?
go to post Benjamin De Boe · Jul 29, 2022 yeah, while I appreciate @Renato Banzai 's creativity in the above article, I can't resist to make a plug for our %Stream classes that can take care of very large strings. Also, starting 2021.2, Stream data is compressed by default, which can easily save you 80% on storage for content such as XML. I have a couple of utilities here that complement this feature by allowing you to compress old stream data in-place.
go to post Benjamin De Boe · Jul 29, 2022 Cool stuff! For this age-old iKnow demo I used import.io to scrape a bunch of hotel reviews from the web, but it was pretty crude and server-based, so impossible to include in the demo repo. I've heard of beautifulsoup before, but never considered revisiting that data sourcing piece of my demo now that we can use it directly through Embedded Python.