On Jul 13, 2013, at 22:59, Michael Bayer <mike...@zzzcomputing.com> wrote:
> The original intent of "default" for Column is that it acts exactly like
> "server_default", except it runs on the Python side for the case that your
> schema wasn't created with this default, or the functionality of your default
> is not supported by the database. But otherwise, just like a
> "server_default", the value is None on the Python side until the INSERT
> occurs.
For what it's worth I forget that all the time and end up flushing objects out
just to get the default values right.
> Really, a better solution here would be an ORM-level "default", that's what
> you've implemented anyway.
In order to keep things pythonic I wonder if this should just be left as
default arguments for the constructor. If everyone would do this:
class Foo(Base):
start_end = sa.Column(sa.Timestamp())
def __init__(self, start_end=datetime(2001, 2, 3), **kw):
Base.__init__(self, start_end. **kw)
This is standard python and easy to read. For association tables you already
need to do this, either this way or by supplying a factory function, so the
step to doing it for other objects is not that big. The downside is that the
default value is now at a different place than the column definition, but it
does make it very clear that this operates at the Python object level instead
of the core SQL level.
Wichert.
--
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 sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
