steampipe_alchemy package

Subpackages

Submodules

steampipe_alchemy.db module

class steampipe_alchemy.db.AwsConfig(**kwargs)

Bases: dict

profile: str
regions: List[str]
class steampipe_alchemy.db.Query(entities, session=None)[source]

Bases: Generic[steampipe_alchemy.db.T], sqlalchemy.orm.query.Query

Wrapper around sqlalchemy.orm.Query that supports type annotations.

The Query object can be used as it self or as an iterable over the model. When used as an iterable it does not provide autocomplete of the underlying class by default. i.e.

for i in sess.query(Model).all():

…

Here i will be an object of type Model but because of the dynamic nature of sqlalchemy we need to add a type hint to get completion to work correctly.

i: Model

Putting this everywhere is kinda a pain though, so instead this class can be used with a custom query method (below) to automatically set the right type.

add_columns(*column) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Add one or more column expressions to the list of result columns to be returned.

add_entity(entity, alias=None) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

add a mapped entity to the list of result columns to be returned.

all() → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return the results represented by this _query.Query as a list.

This results in an execution of the underlying SQL statement.

Warning

The _query.Query object, when asked to return either a sequence or iterator that consists of full ORM-mapped entities, will deduplicate entries based on primary key. See the FAQ for more details.

See also

faq_query_deduplicating

autoflush(setting) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a Query with a specific ‘autoflush’ setting.

As of SQLAlchemy 1.4, the _orm.Query.autoflush() method is equivalent to using the autoflush execution option at the ORM level. See the section orm_queryguide_autoflush for further background on this option.

correlate(*fromclauses) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a Query construct which will correlate the given FROM clauses to that of an enclosing Query or select().

The method here accepts mapped classes, aliased() constructs, and mapper() constructs as arguments, which are resolved into expression constructs, in addition to appropriate expression constructs.

The correlation arguments are ultimately passed to _expression.Select.correlate() after coercion to expression constructs.

The correlation arguments take effect in such cases as when _query.Query.from_self() is used, or when a subquery as returned by _query.Query.subquery() is embedded in another _expression.select() construct.

distinct(*expr) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply a DISTINCT to the query and return the newly resulting Query.

Note

The ORM-level distinct() call includes logic that will automatically add columns from the ORDER BY of the query to the columns clause of the SELECT statement, to satisfy the common need of the database backend that ORDER BY columns be part of the SELECT list when DISTINCT is used. These columns are not added to the list of columns actually fetched by the _query.Query, however, so would not affect results. The columns are passed through when using the _query.Query.statement accessor, however.

Deprecated since version 2.0: This logic is deprecated and will be removed in SQLAlchemy 2.0. See migration_20_query_distinct for a description of this use case in 2.0.

Parameters

*expr –

optional column expressions. When present, the PostgreSQL dialect will render a DISTINCT ON (<expressions>) construct.

Deprecated since version 1.4: Using *expr in other dialects is deprecated and will raise _exc.CompileError in a future version.

enable_assertions(value) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Control whether assertions are generated.

When set to False, the returned Query will not assert its state before certain operations, including that LIMIT/OFFSET has not been applied when filter() is called, no criterion exists when get() is called, and no “from_statement()” exists when filter()/order_by()/group_by() etc. is called. This more permissive mode is used by custom Query subclasses to specify criterion or other modifiers outside of the usual usage patterns.

Care should be taken to ensure that the usage pattern is even possible. A statement applied by from_statement() will override any criterion set by filter() or order_by(), for example.

enable_eagerloads(value) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Control whether or not eager joins and subqueries are rendered.

When set to False, the returned Query will not render eager joins regardless of joinedload(), subqueryload() options or mapper-level lazy='joined'/lazy='subquery' configurations.

This is used primarily when nesting the Query’s statement into a subquery or other selectable, or when using _query.Query.yield_per().

execution_options(**kwargs) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Set non-SQL options which take effect during execution.

Options allowed here include all of those accepted by _engine.Connection.execution_options(), as well as a series of ORM specific options:

populate_existing=True - equivalent to using _orm.Query.populate_existing()

autoflush=True|False - equivalent to using _orm.Query.autoflush()

yield_per=<value> - equivalent to using _orm.Query.yield_per()

Note that the stream_results execution option is enabled automatically if the yield_per() method or execution option is used.

The execution options may also be specified on a per execution basis when using 2.0 style queries via the :paramref:`_orm.Session.execution_options` parameter.

New in version 1.4: - added ORM options to _orm.Query.execution_options()

See also

engine_stream_results

_query.Query.get_execution_options()

filter(*criterion) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply the given filtering criterion to a copy of this _query.Query, using SQL expressions.

e.g.:

session.query(MyClass).filter(MyClass.name == 'some name')

Multiple criteria may be specified as comma separated; the effect is that they will be joined together using the and_() function:

session.query(MyClass).\
    filter(MyClass.name == 'some name', MyClass.id > 5)

The criterion is any SQL expression object applicable to the WHERE clause of a select. String expressions are coerced into SQL expression constructs via the _expression.text() construct.

See also

_query.Query.filter_by() - filter on keyword expressions.

from_statement(statement) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Execute the given SELECT statement and return results.

This method bypasses all internal statement compilation, and the statement is executed without modification.

The statement is typically either a _expression.text() or _expression.select() construct, and should return the set of columns appropriate to the entity class represented by this _query.Query.

See also

orm_tutorial_literal_sql - usage examples in the ORM tutorial

group_by(*clauses) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply one or more GROUP BY criterion to the query and return the newly resulting _query.Query.

All existing GROUP BY settings can be suppressed by passing None - this will suppress any GROUP BY configured on mappers as well.

See also

These sections describe GROUP BY in terms of 2.0 style invocation but apply to _orm.Query as well:

tutorial_group_by_w_aggregates - in the unified_tutorial

tutorial_order_by_label - in the unified_tutorial

having(criterion) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply a HAVING criterion to the query and return the newly resulting _query.Query.

_query.Query.having() is used in conjunction with _query.Query.group_by().

HAVING criterion makes it possible to use filters on aggregate functions like COUNT, SUM, AVG, MAX, and MIN, eg.:

q = session.query(User.id).\
            join(User.addresses).\
            group_by(User.id).\
            having(func.count(Address.id) > 2)
join(target, *props, **kwargs) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Create a SQL JOIN against this _query.Query object’s criterion and apply generatively, returning the newly resulting _query.Query.

Simple Relationship Joins

Consider a mapping between two classes User and Address, with a relationship User.addresses representing a collection of Address objects associated with each User. The most common usage of _query.Query.join() is to create a JOIN along this relationship, using the User.addresses attribute as an indicator for how this should occur:

q = session.query(User).join(User.addresses)

Where above, the call to _query.Query.join() along User.addresses will result in SQL approximately equivalent to:

SELECT user.id, user.name
FROM user JOIN address ON user.id = address.user_id

In the above example we refer to User.addresses as passed to _query.Query.join() as the “on clause”, that is, it indicates how the “ON” portion of the JOIN should be constructed.

To construct a chain of joins, multiple _query.Query.join() calls may be used. The relationship-bound attribute implies both the left and right side of the join at once:

q = session.query(User).\
        join(User.orders).\
        join(Order.items).\
        join(Item.keywords)

Note

as seen in the above example, the order in which each call to the join() method occurs is important. Query would not, for example, know how to join correctly if we were to specify User, then Item, then Order, in our chain of joins; in such a case, depending on the arguments passed, it may raise an error that it doesn’t know how to join, or it may produce invalid SQL in which case the database will raise an error. In correct practice, the _query.Query.join() method is invoked in such a way that lines up with how we would want the JOIN clauses in SQL to be rendered, and each call should represent a clear link from what precedes it.

Joins to a Target Entity or Selectable

A second form of _query.Query.join() allows any mapped entity or core selectable construct as a target. In this usage, _query.Query.join() will attempt to create a JOIN along the natural foreign key relationship between two entities:

q = session.query(User).join(Address)

In the above calling form, _query.Query.join() is called upon to create the “on clause” automatically for us. This calling form will ultimately raise an error if either there are no foreign keys between the two entities, or if there are multiple foreign key linkages between the target entity and the entity or entities already present on the left side such that creating a join requires more information. Note that when indicating a join to a target without any ON clause, ORM configured relationships are not taken into account.

Joins to a Target with an ON Clause

The third calling form allows both the target entity as well as the ON clause to be passed explicitly. A example that includes a SQL expression as the ON clause is as follows:

q = session.query(User).join(Address, User.id==Address.user_id)

The above form may also use a relationship-bound attribute as the ON clause as well:

q = session.query(User).join(Address, User.addresses)

The above syntax can be useful for the case where we wish to join to an alias of a particular target entity. If we wanted to join to Address twice, it could be achieved using two aliases set up using the aliased() function:

a1 = aliased(Address)
a2 = aliased(Address)

q = session.query(User).\
        join(a1, User.addresses).\
        join(a2, User.addresses).\
        filter(a1.email_address=='ed@foo.com').\
        filter(a2.email_address=='ed@bar.com')

The relationship-bound calling form can also specify a target entity using the _orm.PropComparator.of_type() method; a query equivalent to the one above would be:

a1 = aliased(Address)
a2 = aliased(Address)

q = session.query(User).\
        join(User.addresses.of_type(a1)).\
        join(User.addresses.of_type(a2)).\
        filter(a1.email_address == 'ed@foo.com').\
        filter(a2.email_address == 'ed@bar.com')

Augmenting Built-in ON Clauses

As a substitute for providing a full custom ON condition for an existing relationship, the _orm.PropComparator.and_() function may be applied to a relationship attribute to augment additional criteria into the ON clause; the additional criteria will be combined with the default criteria using AND:

q = session.query(User).join(
    User.addresses.and_(Address.email_address != 'foo@bar.com')
)

New in version 1.4.

Joining to Tables and Subqueries

The target of a join may also be any table or SELECT statement, which may be related to a target entity or not. Use the appropriate .subquery() method in order to make a subquery out of a query:

subq = session.query(Address).\
    filter(Address.email_address == 'ed@foo.com').\
    subquery()


q = session.query(User).join(
    subq, User.id == subq.c.user_id
)

Joining to a subquery in terms of a specific relationship and/or target entity may be achieved by linking the subquery to the entity using _orm.aliased():

subq = session.query(Address).\
    filter(Address.email_address == 'ed@foo.com').\
    subquery()

address_subq = aliased(Address, subq)

q = session.query(User).join(
    User.addresses.of_type(address_subq)
)

Controlling what to Join From

In cases where the left side of the current state of _query.Query is not in line with what we want to join from, the _query.Query.select_from() method may be used:

q = session.query(Address).select_from(User).\
                join(User.addresses).\
                filter(User.name == 'ed')

Which will produce SQL similar to:

SELECT address.* FROM user
    JOIN address ON user.id=address.user_id
    WHERE user.name = :name_1

Legacy Features of Query.join()

Deprecated since version 1.4: The following features are deprecated and will be removed in SQLAlchemy 2.0.

The _query.Query.join() method currently supports several usage patterns and arguments that are considered to be legacy as of SQLAlchemy 1.3. A deprecation path will follow in the 1.4 series for the following features:

  • Joining on relationship names rather than attributes:

    session.query(User).join("addresses")

    Why it’s legacy: the string name does not provide enough context for _query.Query.join() to always know what is desired, notably in that there is no indication of what the left side of the join should be. This gives rise to flags like from_joinpoint as well as the ability to place several join clauses in a single _query.Query.join() call which don’t solve the problem fully while also adding new calling styles that are unnecessary and expensive to accommodate internally.

    Modern calling pattern: Use the actual relationship, e.g. User.addresses in the above case:

    session.query(User).join(User.addresses)

  • Automatic aliasing with the aliased=True flag:

    session.query(Node).join(Node.children, aliased=True).\
    filter(Node.name == 'some name')

    Why it’s legacy: the automatic aliasing feature of _query.Query is intensely complicated, both in its internal implementation as well as in its observed behavior, and is almost never used. It is difficult to know upon inspection where and when its aliasing of a target entity, Node in the above case, will be applied and when it won’t, and additionally the feature has to use very elaborate heuristics to achieve this implicit behavior.

    Modern calling pattern: Use the _orm.aliased() construct explicitly:

    from sqlalchemy.orm import aliased

n1 = aliased(Node)

session.query(Node).join(Node.children.of_type(n1)).\
    filter(n1.name == 'some name')

  • Multiple joins in one call:

    session.query(User).join("orders", "items")

session.query(User).join(User.orders, Order.items)

session.query(User).join(
    (Order, User.orders),
    (Item, Item.order_id == Order.id)
)

session.query(User).join(Order, Item)

# ... and several more forms actually

    Why it’s legacy: being able to chain multiple ON clauses in one call to _query.Query.join() is yet another attempt to solve the problem of being able to specify what entity to join from, and is the source of a large variety of potential calling patterns that are internally expensive and complicated to parse and accommodate.

    Modern calling pattern: Use relationship-bound attributes or SQL-oriented ON clauses within separate calls, so that each call to _query.Query.join() knows what the left side should be:

    session.query(User).join(User.orders).join(
    Item, Item.order_id == Order.id)
Parameters

  • *props – Incoming arguments for _query.Query.join(), the props collection in modern use should be considered to be a one or two argument form, either as a single “target” entity or ORM attribute-bound relationship, or as a target entity plus an “on clause” which may be a SQL expression or ORM attribute-bound relationship.

  • isouter=False – If True, the join used will be a left outer join, just as if the _query.Query.outerjoin() method were called.

  • full=False –

    render FULL OUTER JOIN; implies isouter.

    New in version 1.1.

  • from_joinpoint=False –

    When using aliased=True, a setting of True here will cause the join to be from the most recent joined target, rather than starting back from the original FROM clauses of the query.

    Note

    This flag is considered legacy.

  • aliased=False –

    If True, indicate that the JOIN target should be anonymously aliased. Subsequent calls to _query.Query.filter() and similar will adapt the incoming criterion to the target alias, until _query.Query.reset_joinpoint() is called.

    Note

    This flag is considered legacy.

See also

ormtutorial_joins in the ORM tutorial.

inheritance_toplevel for details on how _query.Query.join() is used for inheritance relationships.

_orm.join() - a standalone ORM-level join function, used internally by _query.Query.join(), which in previous SQLAlchemy versions was the primary ORM-level joining interface.

limit(limit: int) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply a LIMIT to the query and return the newly resulting Query.

offset(offset) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply an OFFSET to the query and return the newly resulting Query.

only_return_tuples(value) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

When set to True, the query results will always be a tuple.

This is specifically for single element queries. The default is False.

New in version 1.2.5.

See also

_query.Query.is_single_entity()

options(*args) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a new _query.Query object, applying the given list of mapper options.

Most supplied options regard changing how column- and relationship-mapped attributes are loaded.

See also

deferred_options

relationship_loader_options

order_by(*clauses) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Apply one or more ORDER BY criterion to the query and return the newly resulting _query.Query.

All existing ORDER BY settings can be suppressed by passing None.

See also

These sections describe ORDER BY in terms of 2.0 style invocation but apply to _orm.Query as well:

tutorial_order_by - in the unified_tutorial

tutorial_order_by_label - in the unified_tutorial

params(*args, **kwargs) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Add values for bind parameters which may have been specified in filter().

Parameters may be specified using **kwargs, or optionally a single dictionary as the first positional argument. The reason for both is that **kwargs is convenient, however some parameter dictionaries contain unicode keys in which case **kwargs cannot be used.

populate_existing() → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a _query.Query that will expire and refresh all instances as they are loaded, or reused from the current Session.

As of SQLAlchemy 1.4, the _orm.Query.populate_existing() method is equivalent to using the populate_existing execution option at the ORM level. See the section orm_queryguide_populate_existing for further background on this option.

reset_joinpoint() → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a new Query, where the “join point” has been reset back to the base FROM entities of the query.

This method is usually used in conjunction with the aliased=True feature of the join() method. See the example in join() for how this is used.

select_entity_from(from_obj) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Set the FROM clause of this _query.Query to a core selectable, applying it as a replacement FROM clause for corresponding mapped entities.

Deprecated since version 1.4: The _orm.Query.select_entity_from() method is considered legacy as of the 1.x series of SQLAlchemy and will be removed in 2.0. Use the _orm.aliased() construct instead (Background on SQLAlchemy 2.0 at: migration_20_toplevel)

The _query.Query.select_entity_from() method supplies an alternative approach to the use case of applying an aliased() construct explicitly throughout a query. Instead of referring to the aliased() construct explicitly, _query.Query.select_entity_from() automatically adapts all occurrences of the entity to the target selectable.

Given a case for aliased() such as selecting User objects from a SELECT statement:

select_stmt = select(User).where(User.id == 7)
user_alias = aliased(User, select_stmt)

q = session.query(user_alias).\
    filter(user_alias.name == 'ed')

Above, we apply the user_alias object explicitly throughout the query. When it’s not feasible for user_alias to be referenced explicitly in many places, _query.Query.select_entity_from() may be used at the start of the query to adapt the existing User entity:

q = session.query(User).\
    select_entity_from(select_stmt.subquery()).\
    filter(User.name == 'ed')

Above, the generated SQL will show that the User entity is adapted to our statement, even in the case of the WHERE clause:

SELECT anon_1.id AS anon_1_id, anon_1.name AS anon_1_name
FROM (SELECT "user".id AS id, "user".name AS name
FROM "user"
WHERE "user".id = :id_1) AS anon_1
WHERE anon_1.name = :name_1

The _query.Query.select_entity_from() method is similar to the _query.Query.select_from() method, in that it sets the FROM clause of the query. The difference is that it additionally applies adaptation to the other parts of the query that refer to the primary entity. If above we had used _query.Query.select_from() instead, the SQL generated would have been:

-- uses plain select_from(), not select_entity_from()
SELECT "user".id AS user_id, "user".name AS user_name
FROM "user", (SELECT "user".id AS id, "user".name AS name
FROM "user"
WHERE "user".id = :id_1) AS anon_1
WHERE "user".name = :name_1

To supply textual SQL to the _query.Query.select_entity_from() method, we can make use of the _expression.text() construct. However, the _expression.text() construct needs to be aligned with the columns of our entity, which is achieved by making use of the _expression.TextClause.columns() method:

text_stmt = text("select id, name from user").columns(
    User.id, User.name).subquery()
q = session.query(User).select_entity_from(text_stmt)

_query.Query.select_entity_from() itself accepts an aliased() object, so that the special options of aliased() such as :paramref:`.aliased.adapt_on_names` may be used within the scope of the _query.Query.select_entity_from() method’s adaptation services. Suppose a view user_view also returns rows from user. If we reflect this view into a _schema.Table, this view has no relationship to the _schema.Table to which we are mapped, however we can use name matching to select from it:

user_view = Table('user_view', metadata,
                  autoload_with=engine)
user_view_alias = aliased(
    User, user_view, adapt_on_names=True)
q = session.query(User).\
    select_entity_from(user_view_alias).\
    order_by(User.name)

Changed in version 1.1.7: The _query.Query.select_entity_from() method now accepts an aliased() object as an alternative to a _expression.FromClause object.

Parameters

from_obj – a _expression.FromClause object that will replace the FROM clause of this _query.Query. It also may be an instance of aliased().

See also

_query.Query.select_from()

select_from(*from_obj) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Set the FROM clause of this Query explicitly.

Query.select_from() is often used in conjunction with Query.join() in order to control which entity is selected from on the “left” side of the join.

The entity or selectable object here effectively replaces the “left edge” of any calls to join(), when no joinpoint is otherwise established - usually, the default “join point” is the leftmost entity in the Query object’s list of entities to be selected.

A typical example:

q = session.query(Address).select_from(User).\
    join(User.addresses).\
    filter(User.name == 'ed')

Which produces SQL equivalent to:

SELECT address.* FROM user
JOIN address ON user.id=address.user_id
WHERE user.name = :name_1
Parameters

*from_obj – collection of one or more entities to apply to the FROM clause. Entities can be mapped classes, AliasedClass objects, Mapper objects as well as core FromClause elements like subqueries.

Changed in version 0.9: This method no longer applies the given FROM object to be the selectable from which matching entities select from; the select_entity_from() method now accomplishes this. See that method for a description of this behavior.

See also

join()

Query.select_entity_from()

slice(start, stop) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Computes the “slice” of the _query.Query represented by the given indices and returns the resulting _query.Query.

The start and stop indices behave like the argument to Python’s built-in range() function. This method provides an alternative to using LIMIT/OFFSET to get a slice of the query.

For example,

session.query(User).order_by(User.id).slice(1, 3)

renders as

SELECT users.id AS users_id,
       users.name AS users_name
FROM users ORDER BY users.id
LIMIT ? OFFSET ?
(2, 1)

See also

_query.Query.limit()

_query.Query.offset()

where(*criterion) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

A synonym for Query.filter().

New in version 1.4.

with_entities(*entities) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a new _query.Query replacing the SELECT list with the given entities.

e.g.:

# Users, filtered on some arbitrary criterion
# and then ordered by related email address
q = session.query(User).\
            join(User.address).\
            filter(User.name.like('%ed%')).\
            order_by(Address.email)

# given *only* User.id==5, Address.email, and 'q', what
# would the *next* User in the result be ?
subq = q.with_entities(Address.email).\
            order_by(None).\
            filter(User.id==5).\
            subquery()
q = q.join((subq, subq.c.email < Address.email)).\
            limit(1)
with_for_update(read=False, nowait=False, of=None, skip_locked=False, key_share=False) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

return a new _query.Query with the specified options for the FOR UPDATE clause.

The behavior of this method is identical to that of _expression.GenerativeSelect.with_for_update(). When called with no arguments, the resulting SELECT statement will have a FOR UPDATE clause appended. When additional arguments are specified, backend-specific options such as FOR UPDATE NOWAIT or LOCK IN SHARE MODE can take effect.

E.g.:

q = sess.query(User).populate_existing().with_for_update(nowait=True, of=User)

The above query on a PostgreSQL backend will render like:

SELECT users.id AS users_id FROM users FOR UPDATE OF users NOWAIT

Note

It is generally a good idea to combine the use of the _orm.Query.populate_existing() method when using the _orm.Query.with_for_update() method. The purpose of _orm.Query.populate_existing() is to force all the data read from the SELECT to be populated into the ORM objects returned, even if these objects are already in the identity map.

See also

_expression.GenerativeSelect.with_for_update() - Core level method with full argument and behavioral description.

_orm.Query.populate_existing() - overwrites attributes of objects already loaded in the identity map.

with_session(session) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Return a _query.Query that will use the given Session.

While the _query.Query object is normally instantiated using the Session.query() method, it is legal to build the _query.Query directly without necessarily using a Session. Such a _query.Query object, or any _query.Query already associated with a different Session, can produce a new _query.Query object associated with a target session using this method:

from sqlalchemy.orm import Query

query = Query([MyClass]).filter(MyClass.id == 5)

result = query.with_session(my_session).one()
yield_per(count) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query][source]

Yield only count rows at a time.

The purpose of this method is when fetching very large result sets (> 10K rows), to batch results in sub-collections and yield them out partially, so that the Python interpreter doesn’t need to declare very large areas of memory which is both time consuming and leads to excessive memory use. The performance from fetching hundreds of thousands of rows can often double when a suitable yield-per setting (e.g. approximately 1000) is used, even with DBAPIs that buffer rows (which are most).

As of SQLAlchemy 1.4, the _orm.Query.yield_per() method is equivalent to using the yield_per execution option at the ORM level. See the section orm_queryguide_yield_per for further background on this option.

class steampipe_alchemy.db.ServiceState(value)[source]

Bases: enum.Enum

An enumeration.

RUNNING = 2
STOPPED = 1
UNKNOWN = 0
class steampipe_alchemy.db.ServiceStatus(state: steampipe_alchemy.db.ServiceState = <ServiceState.UNKNOWN: 0>, reason: str = '')[source]

Bases: object

reason: str = ''
state: steampipe_alchemy.db.ServiceState = 0
class steampipe_alchemy.db.SteamPipe[source]

Bases: object

bin_dir = PosixPath('/home/docs/.local/share/steampipe_alchemy/bin')
get_darwin()[source]
static get_latest() → str[source]
get_linux()[source]
home_dir = PosixPath('/home/docs/.local/share/steampipe_alchemy')
install(plugins: List[str] = [])[source]
install_plugin(plugin: str)[source]
query(resource: steampipe_alchemy.db.T) → Union[Iterable[steampipe_alchemy.db.T], steampipe_alchemy.db.Query[steampipe_alchemy.db.T]][source]

Wrapper around Session.query that supports type annotations.

restart()[source]
set_db(status_out: bytes)[source]
start(**kwargs) → steampipe_alchemy.db.ServiceStatus[source]
status() → steampipe_alchemy.db.ServiceStatus[source]
stop()[source]
update_config(aws: Optional[steampipe_alchemy.db.AwsConfig] = None, **kwargs)[source]
exception steampipe_alchemy.db.UnexpectedStateException[source]

Bases: Exception

steampipe_alchemy.db.install(*args, **kwargs)[source]
steampipe_alchemy.db.install_plugin(*args, **kwargs)[source]
steampipe_alchemy.db.query(*args, **kwargs)[source]
steampipe_alchemy.db.start(**kwargs) → steampipe_alchemy.db.ServiceStatus[source]
steampipe_alchemy.db.stop()[source]
steampipe_alchemy.db.update_config(*args, **kwargs)[source]

Module contents

Top-level package for steampipe-alchemy.