The "SET DEFAULT" is in the old alembic-evolved database only. As I said, I'm pretty sure I never set this up in the code anywhere (it was always using the client-side default values).
On Saturday, 11 October 2014 10:24:22 UTC+11, Michael Bayer wrote: > > > server_default is what you want for the most foolproof system of putting > in default values, because the database does it. Is the “SET DEFAULT” > thing there the old or the new database? > > > On Oct 10, 2014, at 6:41 PM, gbr <[email protected] <javascript:>> > wrote: > > The weird thing is that this problem only arose when I wanted to create a > database of my application from scratch (using metadata.create_all()). The > old database instance had undergone various alembic evolutions and when I > check in pgAdmin, the column definition for this column says: > > ALTER TABLE user ADD COLUMN admin boolean; > ALTER TABLE user ALTER COLUMN admin SET DEFAULT false; > > This indicates that `server_default` was used, but I don't think I've ever > defined it this way. Could alembic at some stage have misinterpreted the > `default=False` with `server_default=False`? > > I'll probably change to `server_default`... > > On Saturday, 11 October 2014 09:28:32 UTC+11, gbr wrote: >> >> I didn't know 1.0 was out already. How can I upgrade to it? `pip` and >> `easy_install` still install 0.9.7... >> >> On Saturday, 11 October 2014 08:50:05 UTC+11, Michael Bayer wrote: >>> >>> I’ve implemented this feature in 1.0. When you upgrade to 1.0, the >>> default values will be included in the SELECT statement automatically. >>> >>> See >>> http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html#insert-from-select-now-includes-python-and-sql-expression-defaults >>> >>> . >>> >>> >>> >>> On Oct 10, 2014, at 10:39 AM, Michael Bayer <[email protected]> >>> wrote: >>> >>> this is a documented limitation: >>> >>> >>> http://docs.sqlalchemy.org/en/rel_0_9/core/dml.html?highlight=from_select#sqlalchemy.sql.expression.Insert.from_select >>> >>> Note >>> >>> A SELECT..INSERT construct in SQL has no VALUES clause. Therefore Column >>> <http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html#sqlalchemy.schema.Column> >>> >>> objects which utilize Python-side defaults (e.g. as described at >>> *metadata_defaults_toplevel*) will *not* take effect when using Insert. >>> from_select() >>> <http://docs.sqlalchemy.org/en/rel_0_9/core/dml.html?highlight=from_select#sqlalchemy.sql.expression.Insert.from_select> >>> . >>> >>> use a server-side default instead. >>> >>> >>> >>> >>> On Oct 10, 2014, at 5:12 AM, gbr <[email protected]> wrote: >>> >>> Given this example, I would expect that in both cases the default value >>> of user.admin gets set. >>> >>> from sqlalchemy import * >>> from sqlalchemy.ext.declarative import declarative_base >>> from sqlalchemy.orm import sessionmaker, scoped_session >>> >>> engine = create_engine('sqlite:///:memory:', echo=True) >>> Base = declarative_base(bind=engine) >>> Session = scoped_session(sessionmaker(engine)) >>> >>> metadata = Base.metadata >>> >>> user = Table('user', metadata, >>> Column('id', Integer), >>> Column('name', String), >>> Column('admin', Boolean, default=False) >>> ) >>> >>> metadata.create_all() >>> >>> print insert(user).values({'id': 1, 'name': 'Max'}) >>> >>> # this is a contrived example, but it demonstrates the problem >>> print insert(user).from_select([user.c.id, user.c.name], select([ >>> user.c.id, user.c.name]).where(user.c.name=='Max')) >>> >>> >>> The first insert() gets resolved to >>> > INSERT INTO user (id, name, admin) VALUES (?, ?, ?) >>> >>> which is fine, but the second intert().from_select() does not gets admin >>> set. >>> > INSERT INTO user (id, name) SELECT user.id, user.name FROM user WHERE >>> user.name = ? >>> >>> >>> >>> -- >>> 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. >>> >>> >>> >>> -- >>> 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. >>> >>> >>> > -- > 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] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
