Michael Bayer (@zzzeek) wrote:

it says "if c.key in row else param". the param is there, the issue here lies only in the conversion to positional.

Test cases are super helpful, here's mine, which if you use a named format, passes:

from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base
import datetime
Base = declarative_base()

class A(Base):
    __tablename__ = 'a'
    id = Column(Integer, primary_key=True)
    x = Column(Integer)
    created_at = Column(DateTime, default=lambda: datetime.datetime.utcnow())


e = create_engine("postgresql://scott:tiger@localhost/test", echo=True)
Base.metadata.drop_all(e)
Base.metadata.create_all(e)

e.execute(
    A.__table__.insert().values([
        {'x': 5}, {'x': 10}
    ])
)

if we use e = create_engine("postgresql://scott:tiger@localhost/test", echo=True, paramstyle='format') or e = create_engine("sqlite://"), then we get errors. in the second case, I get the same error as yours, so that's how i know this is sqlite! (as opposed to that also being in the bug report explicitly ;) )

Michael Bayer (@zzzeek) wrote:

now what is odd is why that positional conversion isn't working, so in the logic you mention I think we might need to make a new bindparam() object with the same name, perhaps, i need to recall how that case is supposed to work.

Michael Bayer (@zzzeek) wrote:

ok yeah 'param' there is just the string so somehting has to happen that will add an entry to positiontup each time there

Michael Bayer (@zzzeek) wrote:

the contract of Python side default callables is that they be called for each row individually. This functionality is not at all built into the "multi VALUES" facility right now, and will change the behavior of an application that currently makes use of python-callable defaults with a name-based paramstyle. to accomplish this means some major changes in crud.py which I'll do today but this would be definitely too destabilizing for 0.9.

Changes by Michael Bayer (@zzzeek):

• added labels: high priority

Changes by Michael Bayer (@zzzeek):

• set milestone to "1.0"

Michael Bayer (@zzzeek) wrote:

• The multi-values version of :meth:.Insert.values has been
  repaired to work more usefully with tables that have Python-
  side default values and/or functions, as well as server-side
  defaults. The feature will now work with a dialect that uses
  "positional" parameters; a Python callable will also be
  invoked individually for each row just as is the case with an
  "executemany" style invocation; a server- side default column
  will no longer implicitly receive the value explicitly
  specified for the first row, instead refusing to invoke
  without an explicit value. fixes Insert multiple rows fails when using a column's default value #3288

→ 92cc232

Changes by Michael Bayer (@zzzeek):

• changed status to closed

Michael Bayer (@zzzeek) wrote:

that was a total crapshow. there's a migration guide on that one coming up in the next readthedocs build.