On Jun 7, 2014, at 1:21 AM, Michael Weylandt <[email protected]> wrote:
> I'm working with a database (Sybase ASE) which supports a non-null BIT type.
> For Column(Boolean, nullable=False), SQLA's use of BIT is ideal, but I need
> to have Column(Boolean, nullable=True) produce a TINYINT + Check constraint.
>
> The DDL compiler only provides the type (not the full column) to
> visit_Boolean, so that's a bit too low-level to check NULL-ability.
>
> I can get at the column object with sys._get_frame() or by post-processing
> the DDL, but I figured I'd check if SQLA has a native solution.
if this is for the purposes of the Sybase ASE dialect itself, e.g. if we use
BIT with nullable=True it raises an error, then we can introduce a SybaseASE
specific boolean type into the dialect. Boolean types are so-called "schema"
types so they are given access to the column to which they are attached using
the "before_parent_attach" or "after_parent_attach" events. SchemaType itself
also has _set_parent() called with the Column directly. So this is the point
at which this can be intercepted, and a flag can be attached to the type object
that provides for this hint - however, it means the type is now "welded" to
that column, so this is not really an ideal solution, it's buggy in that the
same type can't be used more than once. A 1.0 proposal is below which would
allow more flexibility.
If this is more at the user land level, I'd do a type like this:
class TinyintBoolean(TypeDecorator):
impl = TINYINT
def process_bind_param(self, value, dialect):
return None if value is None else bool(value)
def process_result_value(self, value, dialect):
return bool(value) if value is not None else None
then I'd again intercept "after_parent_attach" on Boolean, and at that point
swap out the Boolean type object on the Column for TinyintBoolean. This is
how you should go for now.
The idea that compilation of a type should be passed the Column or SQL
expression that it is a part of is a good one, as we do typically always have
that available (note that this is not just within DDL - we render types in CAST
expressions as well, but there's still a parent SQL expression). But this
would require a major change to the API of TypeCompiler, all the visit_XYZ()
methods would at least now need to accept **kwargs. Some trickery would be
needed to accommodate old dialects. I've added
https://bitbucket.org/zzzeek/sqlalchemy/issue/3074/allow-kw-for-typecompiler-specifically
which includes a patch but this would be for 1.0 at the earliest.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
