You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This method was entirely redundant with `QueryFragment#to_sql`, and
effectively only exists because `Expression` predates `QueryFragment`,
and I needed to be able to sometimes call `to_insert_sql`. Any cases
that couldn't be covered previously have been removed.
With this change, our heirarchy is much more clear. `QueryFragment`
represents a thing that can be converted to SQL. `Expression` represents
something that represents a SQL type. `Query` represents a typed
`QueryFragment` that can be meaningfully executed.
`Expression` does not have `QueryFragment` as a constraint, but it is
implied that implementing one means you'd implement the other. The
reason I did not add this constraint was that I ultimately intend to
make `QueryFragment` generic over the backend, and I do not want to deal
with that when talking purely about an `Expression`.
I've tried to loosely audit some of the where clauses to avoid putting
too much "type safety" bits in the where clause for `QueryFragment`
impls, and focus on "can be converted to SQL". It's certainly not done,
but I've tried to at the very least not make it any worse. A lot of this
can get cleaned up when I do a pass to attempt to improve specific error
messages.
I need to explitly document this somewhere, but generally a structure
should have no constraints on types in its definition, type safety
should be enforced in `Query` or `Expression` impls, and/or DSL methods,
and memory/serialization safety should be enforced in `QueryFragment`
impls.
0 commit comments