MCPcopy
hub / github.com/sqlalchemy/sqlalchemy / _get_crud_params

Function _get_crud_params

lib/sqlalchemy/sql/crud.py:117–456  ·  view source on GitHub ↗

create a set of tuples representing column/string pairs for use in an INSERT or UPDATE statement. Also generates the Compiled object's postfetch, prefetch, and returning column collections, used for default handling and ultimately populating the CursorResult's prefetch_cols() and po

(
    compiler: SQLCompiler,
    stmt: ValuesBase,
    compile_state: DMLState,
    toplevel: bool,
    **kw: Any,
)

Source from the content-addressed store, hash-verified

115
116
117def _get_crud_params(
118 compiler: SQLCompiler,
119 stmt: ValuesBase,
120 compile_state: DMLState,
121 toplevel: bool,
122 **kw: Any,
123) -> _CrudParams:
124 """create a set of tuples representing column/string pairs for use
125 in an INSERT or UPDATE statement.
126
127 Also generates the Compiled object's postfetch, prefetch, and
128 returning column collections, used for default handling and ultimately
129 populating the CursorResult's prefetch_cols() and postfetch_cols()
130 collections.
131
132 """
133
134 # note: the _get_crud_params() system was written with the notion in mind
135 # that INSERT, UPDATE, DELETE are always the top level statement and
136 # that there is only one of them. With the addition of CTEs that can
137 # make use of DML, this assumption is no longer accurate; the DML
138 # statement is not necessarily the top-level "row returning" thing
139 # and it is also theoretically possible (fortunately nobody has asked yet)
140 # to have a single statement with multiple DMLs inside of it via CTEs.
141
142 # the current _get_crud_params() design doesn't accommodate these cases
143 # right now. It "just works" for a CTE that has a single DML inside of
144 # it, and for a CTE with multiple DML, it's not clear what would happen.
145
146 # overall, the "compiler.XYZ" collections here would need to be in a
147 # per-DML structure of some kind, and DefaultDialect would need to
148 # navigate these collections on a per-statement basis, with additional
149 # emphasis on the "toplevel returning data" statement. However we
150 # still need to run through _get_crud_params() for all DML as we have
151 # Python / SQL generated column defaults that need to be rendered.
152
153 # if there is user need for this kind of thing, it's likely a post 2.0
154 # kind of change as it would require deep changes to DefaultDialect
155 # as well as here.
156
157 compiler.postfetch = []
158 compiler.insert_prefetch = []
159 compiler.update_prefetch = []
160 compiler.implicit_returning = []
161
162 visiting_cte = kw.get("visiting_cte", None)
163 if visiting_cte is not None:
164 # for insert -> CTE -> insert, don't populate an incoming
165 # _crud_accumulate_bind_names collection; the INSERT we process here
166 # will not be inline within the VALUES of the enclosing INSERT as the
167 # CTE is placed on the outside. See issue #9173
168 kw.pop("accumulate_bind_names", None)
169 assert (
170 "accumulate_bind_names" not in kw
171 ), "Don't know how to handle insert within insert without a CTE"
172
173 bindmarkers: MutableMapping[ColumnElement[Any], DMLTargetCopy[Any]] = {}
174 kw["bindmarkers"] = bindmarkers

Callers

nothing calls this directly

Calls 15

_CrudParamsClass · 0.85
_create_bind_paramFunction · 0.85
_column_as_keyFunction · 0.85
_scan_colsFunction · 0.85
_replace_bindmarkersFunction · 0.85
_as_dml_columnFunction · 0.85

Tested by

no test coverage detected