What's New in Version 1.28.0

August 25, 20265:48 PM UTC

Version 1.28.0 of the relationalai Python package is now available!

To upgrade, activate your virtual environment and run the following command:

pip install --upgrade relationalai

New Features and Enhancements

PyRel now records your model’s change history automatically every time you deploy to Snowflake with rai models deploy. This history is called the op log, and it’s what makes rai models branch, pull, and merge work, so those commands now work right away with no setup. To turn recording off, set oplog.enabled: false in raiconfig.yaml.
When you deploy a model, a concept and its subconcepts (declared with extends=) can now be built by different reasoners at the same time. For example, one subconcept can load straight from a Snowflake table while another is derived by rules. Querying the parent concept returns rows from all of its subconcepts together. Previously, every subconcept had to use the same reasoner.
Instead of writing separate SQL queries to explore a Snowflake database table by table, you can now run rai explore schema to capture its full structure (column types, primary and foreign key candidates, and value distributions) as a single JSON file. This helps when you’re building a semantic model from an existing database and want to understand it first. It supports Snowflake sources only for now.

For example:
Terminal window
```
rai explore schema --database DEMO_TELCO --schema RAW --out schema.json
```
You can now define more than one decision problem on the same model, each as its own Problem. Once a model has more than one, give each Problem a unique name using the name parameter so PyRel can tell them apart, and match each one to the same problem every time you redeploy.
You can now use aggregates.string_join in models deployed to Snowflake. Use index= to control the order the values are joined in, or leave it out to join them in ascending order by value.

Bug Fixes

If your deployed model’s target schema also holds tables or views you didn’t create with PyRel, tearing down the model no longer removes them. rai models teardown now deletes only the objects RelationalAI created, and never drops the schema itself, even with --force. If RelationalAI created the schema, teardown reports it separately, along with the SQL needed to remove it.
Deploying a model no longer crashes with ExtractionError: Property owner must be user schema object when it adds a property to a built-in concept. This came up in many common models, such as any model that uses the graph or prescriptive reasoner, or that simply calls Error.new(message=...). If you set oplog.enabled: false only to work around this crash, you can now remove that setting.
In a deployed model, grouped aggregate queries now return correct results when a grouped aggregate (using .per()) shares a variable with another aggregate or lookup in the same rule. Some of these queries previously returned wrong rows, too few rows, or were rejected. Only deployed models were affected.
In a deployed model, an aggregate combined with a fallback value using | (for example, count(C).per(C.grp) | 0) now returns one correct row per group. Before, it could return wrong rows, or the deploy could fail on Snowflake with Unsupported subquery type cannot be evaluated. Only deployed models were affected.
A query that uses union() to express an OR condition across differently filtered joins no longer fails to deploy to Snowflake with Unsupported subquery type cannot be evaluated.
In a deployed model, a concept with a property derived from another of its own properties no longer fails to deploy when nothing else in the model creates that concept. It now deploys with zero rows, which matches the fact that nothing populates it.
A model no longer fails to deploy to Snowflake with an error like invalid identifier '__VAR_N' when a filtered, grouped aggregate is used to classify an existing entity, such as model.where(R(x), c := per(x).count(y), c > 1).define(Flag(x)).
A model with a concept that uses implicit identity no longer silently drops rows when the same data is read more than once during deploy. No model changes are needed. Redeploying applies the fix.
Compiling a model with a large union(), such as hundreds of filter fragments feeding one rule, is now much faster. A compile that used to take over a minute now finishes in a few seconds.
If your deployment role can’t change Snowflake log or trace levels, deploying no longer shows a false Deploy Step Skipped warning when your role already inherits a sufficient level from the account, database, or schema. The warning still appears when the level really is too low, which you can fix by granting your role the MODIFY LOG LEVEL and MODIFY TRACE LEVEL privileges.