关于SQLAlchemy Unique Object模式实现的技术疑问

Great questions! Let's break down each one with SQLAlchemy internals in mind, since that's key to understanding why the original implementation does what it does.

1. Why wrap the query in no_autoflush? #

SQLAlchemy's default autoflush behavior triggers a flush of pending changes to the database whenever you run a query. This is usually helpful to ensure your query sees the latest state of the session, but in the context of a "get or create" method like this, it's problematic.

Here's why:

• Suppose your session already has unflushed changes (e.g., another object with missing required fields). When you run session.query(cls).filter_by(**kwargs).first(), autoflush would attempt to push those incomplete changes to the database, which would throw an error—even though your get_unique call itself is perfectly valid.
• The goal here is to check the database for an existing record without accidentally committing half-finished work from elsewhere in the session. Wrapping the query in no_autoflush isolates this operation from the rest of the session's pending changes.

If you left this up to developers, you'd end up with inconsistent behavior: some would remember to disable autoflush, others wouldn't, leading to hard-to-debug errors that aren't directly related to the get_unique logic. The original implementation (and Wikipedia's version) standardizes this to avoid those surprises.

2. Why add a custom cache when the Session already manages objects? #

SQLAlchemy's Session uses an identity map to cache objects by their primary key—but this only works for objects that have been persisted (i.e., have a primary key assigned). The custom cache here solves two gaps the identity map doesn't cover:

• Unpersisted objects: When you create a new instance with cls(**kwargs) and add it to the session, it doesn't have a primary key yet (until flush/commit). The identity map can't track it by PK, so if you call get_unique again with the same kwargs before flushing, the session would query the database (find nothing) and create a duplicate instance. The custom cache uses the kwargs tuple as a key, so it returns the existing unpersisted object instead.
• Deleted objects: The was_deleted(o) check handles cases where the object was deleted in the same session but not yet flushed. The identity map still holds the deleted object, but we don't want to return it—we need to re-query the database or create a new instance. The custom cache lets us invalidate the cached entry when the object is marked as deleted.

In short, the Session's built-in caching is PK-centric, while get_unique needs caching based on the unique criteria (kwargs) to avoid duplicates and handle edge cases with unpersisted/deleted objects.

3. Is the simplified implementation problematic? #

Yes, it has two critical issues that will cause bugs in real-world use:

• Duplicate object creation: If you call get_unique twice with the same kwargs in the same session before flushing, the first call creates an object and adds it to the session (but it's not in the database yet). The second call runs session.query(...).first()—since the object isn't persisted, the query returns None, and the method creates a second identical object. When you finally flush the session, you'll get a database error for violating the unique constraint.
• Unexpected autoflush errors: As explained in question 1, if the session has pending incomplete changes, running the query will trigger autoflush and throw errors unrelated to your get_unique call.

For example, this code would fail with the simplified version:

with session.begin():
    # First call creates an unpersisted object
    obj1 = Model.get_unique(session, name="test")
    # Second call creates a duplicate
    obj2 = Model.get_unique(session, name="test")
    print(obj1 is obj2)  # False—two separate objects!
# Flush will throw unique constraint violation

The original implementation avoids this by caching the object based on kwargs, ensuring only one instance is created per session for the same unique criteria.

内容的提问来源于stack exchange，提问作者TrilceAC