sqlalchemy-oso 0.7.0

Breaking changes

Removed unused parameter from sqlalchemy_oso.roles.resource_role_class() ( #925)

The first positional parameter to sqlalchemy_oso.roles.resource_role_class(), declarative_base, was no longer used and is now removed. To migrate existing code that uses sqlalchemy_oso.roles.resource_role_class(), simply remove the first parameter from the function invocation.

Option to enable baked queries for authorized sessions has been removed ( #879)

In release 0.6.2, we disabled baked queries by default because of the risk of unintentionally bypassing authorization, but we allowed users who understood the risks to override that default by passing enable_baked_queries=True to any of the authorized session factories.

In this release, we’ve removed that escape hatch out of an abundance of caution. Passing enable_baked_queries=True to any of the authorized session factories will no longer have any effect. If you have a good reason for wanting to enable baked queries on authorized sessions, please reach out on Slack. We would love to hear about it!

New features

Support for SQLAlchemy 1.4 ( #879)

The sqlalchemy-oso library now supports SQLAlchemy 1.4!

If you’re already using sqlalchemy-oso with SQLAlchemy 1.3, upgrading to SQLAlchemy 1.4 requires zero code changes (for sqlalchemy-oso, that is — you might have to update some SQLAlchemy code).

There’s a single (non-breaking) API change: sqlalchemy_oso.register_models() now accepts either a declarative base class (if you’re using SQLAlchemy 1.3 or 1.4) or a registry (if you’re using 1.4).

If you run into any issues with SQLAlchemy 1.4, please don’t hesitate to reach out on Slack or open a new GitHub issue.

Happy SQLAlchemy-ing!

Other bugs & improvements

• Relaxed minimum SQLAlchemy 1.3 version to 1.3.17, when the sqlalchemy.orm.relationship.sync_backref flag was added. ( #879)

sqlalchemy-oso-preview 0.0.4

Breaking changes

Resource Model Primary Key Requirements ( #909)

All resource models used with roles must use the same type in the database for their primary id.

For example:

class Organization(Base):
    __tablename__ = "organizations"

    id = Column(String(), primary_key=True)

class Repository(Base):
    __tablename__ = "repositories"

    id = Column(String(), primary_key=True)
    org_id = Column(String(), ForeignKey("organizations.id"), index=True)
    org = relationship("Organization")

Both Organization and Repository have their primary key column as type String() so this would work. They could both be some other type such as Integer() but you could not have one as String() and the other as Integer().

Connect with us on Slack

If you have any questions, or just want to talk something through, jump into Slack. An Oso engineer or one of the thousands of developers in the growing community will be happy to help.