extended is not the same as unlimited :-)

We're moving from 32-bit block numbers to 40-bit block numbers, which means the max size for a database with 8k block size is 8PB. Obviously, those are huge amounts of data, and we strongly recommend against just stashing that all in a single IRIS.DAT file,, if your file system permits such files at all. Multivolume database support already helps you spread data across multiple physical files (opaquely), and the new Table Partitioning support (experimental in 2026.1) helps you spread table data across multiple databases. 

If you wonder why we stuck with 40 bit numbers rather than a power of 2: we were able to reuse a few available bits in the current block header format, meaning you can transparently and instantly upgrade to this Extended Database Format without having to migrate your almost-32TB database to a new block header format. And 8PB is quite large already...

We found a small issue affecting some Vector Search queries that may lead to a runtime error when your vector search query uses aliases to shorten or disambiguate table names. The problem can be worked around by rewriting your query to avoid using aliases. A fix for this issue will be included in the next preview kit, due in two weeks.

We also identified a separate issue with unintended changes to DSTIME behaviour, and recommend DSTIME users to skip this preview. The next preview kit will restore the original DSTIME behaviour.

I got completely distracted by this article's use of "Dynamic SQL". Dynamic SQL is a fairly specific concept on our platform, and historically there's been a small difference between Dynamic and Embedded SQL in terms of overhead, but that has all but evaporated over the past few years by consecutive optimizations. Now suddenly this article seems to suggest there's a huge gap, so I got hooked and dug into the code, only to find that this method is making a rather crazy detour through %DynamicObject for no real reason, on the way from the SQL result set to the dataframe. In other words, all you're measuring between the "Dynamic SQL" and "IRIS SQL" options is exactly that %DynamicObject overhead.

It's only a name, true, but people only doing a cursory read of the article may take away the completely wrong thing.

Still a test case would be helpful.

If there's no source table rows for which userActionten=1, that value will not show up as a dimension member in Analyzer (so no row in the pivot with COUNT equal to zero). Maybe that's what you're seeing? 

Feel free to share your thoughts here, so we can make sure the AI bot's contributions are appropriately labelled. And indeed we don't want that bot to scoop up all of our precious Global Masters swag! :-)

that first line is required to initialize the mbChunk variable used in the loop, else you'd get an UNDEFINED at runtime.

I'm thinking the way how you're using this macro is slightly off, and this has the same root cause as the other thread you opened. This macro is expected to be used on its own:

  // some logic here
  $$$AndBits(^glo1,^glo2)
  // more logic here, and note there's at least a space before all these lines

hope this helps

I think @Alexander Koblov actually meant "Yes" :-), as row-level security was indeed designed for exactly this purpose, to inject additional filters into queries based on their credentials.

Here's an example that combines two bitmaps:

#define AndBits(%dst,%src) ##continue
    set mbChunk=""                                      ##continue
    for {                                               ##continue
        set mbChunk=$o(%dst(mbChunk),1,mbBits)          ##continue
        quit:mbChunk=""                                 ##continue
        set mbBits=$bitlogic(mbBits&%src(mbChunk))      ##continue
        If $bitfind(mbBits,1) {                         ##continue
            Set %dst(mbChunk)=$bitlogic(mbBits)         ##continue
        } Else {                                        ##continue
            Kill %dst(mbChunk)                          ##continue
        }                                               ##continue
    }

Using ##continue helps you avoid cramming everything onto a single line

I think you may lack a space before your macro use. Any line of actual code other than a line labels needs to start with a space or tab.

I agree it's become more of a style preference thing, so absolutely something to have strong opinions and religious debates about :-)

The only thing to avoid is using Dynamic SQL to conveniently build your query and then feed in query parameters through string concatenation rather than as true ?-style parameters. That's a security risk you wouldn't run with Embedded SQL. That's all. Back to the debate! :-)

Sounds fun! Feel free to take a look at this demo (and the other ones in the same folder).

That REST API is indeed for querying iFind indices (hence the direct reference to an index you can provide) and the somewhat confusingly named "query" argument is actually to pass in the iFind search string. The API will then build a full SQL query for you and run it right away. 

Here's the OpenAPI spec for this endpoint (from self-documentation endpoint /api/iKnow/v1/USER/swagger):

  /table/{table}/search:
    post:
      operationId: /table/{table}/search-POST
      summary: |
        Search the given iFind index in the given table
      tags: ["iFind"]
      parameters:
        - $ref: '#/parameters/tableParam'
        - name: RequestBody
          description: JSON object with a list of query-specific arguments
          in: body
          schema:
            type: object
            properties:
              query:
                description: This is the only necessary parameter with no default value. The search terms to query against the iFind index.
                type: string
              index:
                description: the iFind index would be searched against, if you don't specify it, the first found iFind index would be used .
                type: string
              option:
                $ref: '#/definitions/OptionSpec'
              distance:
                description: only valid when option is fuzzy search (when option is 3)
                type: string
                example: "3"
              language:
                description: iKnow-supported language model to apply, for example "en"
                type: string
              includeText:
                description: whether the returned columns should include the column beging indexed by 'index'
                type: integer
                default: 0
                enum: [0, 1] 
              columns:
                description: specify the columns which also needed to be returned. For example, ["column1","column2"] 
                type: array
                example: []
                items:
                  type: string
              highlightSpec:
                $ref: '#/definitions/HighlightSpec'
                description: the parameters needed for Highlight
              rankSpec:
                $ref: '#/definitions/RankSpec'
                description: the parameters needed for Rank
              where:
                description: the valid SQL logical condition statement. For example, "column1 = ? AND column2 = ?"
                type: string
      responses:
        200:
          description: Successful response
          schema:
            type: object
            properties:
              rows:
                type: array
                default: []
                items:
                  type: object

Indeed, and very applicable too as iFind was created in Belgium, pretty much where the little Asterix village is located 🙃

Love it @Luis Angel Pérez Ramos !!

FYI - you can find more examples of iFind search syntax in the class reference for %iFind.Index.Basic

It is part of my job description to say you shouldn't touch internal globals ;-)

see you in Orlando!

FWIW, I would not recommend users touch this global. It is internal and InterSystems may (and does) change how it's used without notice.