Issue: Zip argument #2 must support iteration for pk_row
Author: leerobert
State: closed
Created: 2016-06-16 19:50:45

I cannot figure out this issue for the life of me. On my test database, created primarily by the ORM create_table routines I do not experience this issue. When I deploy the tables to our production database and other users write partitions that listen to one of the ORM databases this issue occurs.
# Models

``` python
class BaseModel(Model):
    """
    The BaseModel defines the abstract model bean 
    that all Models will inherit. It defines the 
    database where extended beans will connect. 
    It also contains the common data fields that all 
    beans will share in common: 

        model_created_at 
            The datetime object for when the bean was created
        model_updated_at
            The datetime object for when the bean was last updated
        status
            The status of the model bean. Provides functionality for 
            performing soft delete of inactive instances, rather than 
            hard deletes of data. 
    """

    model_created_at = DateTimeField(default=datetime.now)
    model_updated_at = DateTimeField(default=None, null=True)
    is_active = BooleanField(default=True)

    class Meta:
        # the database all BaseModel beans will connect
        database = soos_db  

    def save(self, *args, **kwargs):
        """
        Overrides the peewee save functionality to allow for
        updating of the updated_at datetime field. 
        """
        self.model_updated_at = datetime.now()
        return super(BaseModel, self).save(*args, **kwargs)

    def soft_delete(self):
        """
        Does a soft delete of all beans by giving a status of 
        deleted to the instance and changing the is_active
        flag to False. 
        """
        self.is_active = False
        return self.save()

    def __repr__(self):
        """
        Defines the 'toString' functionality for all extended
        models. It grabs the class name, field names, and field
        values associated to the extended class and displays it
        when str or other repr displays are made on the object. 
        """
        field_values = [ ' {0}:{1}'.format(field, getattr(self, field)) 
            for field in self._meta.fields.keys() ]
        return '<' + self.__class__.__name__ + ''.join(field_values) + '>'

class SOOSItem(BaseModel):
    """
    The SOOSItem is the base scanned out of stock item
    """
    item = ForeignKeyField(Item)
    site = ForeignKeyField(Site)
    vendor = ForeignKeyField(Vendor, null=True)
    manufacturer = ForeignKeyField(Manufacturer, null=True)
    retailer = ForeignKeyField(Retailer, null=True)

    upc = CharField(max_length=13)
    description = CharField()
    price = FloatField()
    quantity_sold = FloatField()
    quantity_sold_weekly = FloatField()
    in_inventory = FloatField()
    lost_sales = FloatField()
    scanned_at = DateTimeField()
```

Here is some example data that I throw in to create the SOOSItem model. 

``` python
>>> data = {'item': Item.get(id=2324), 'site': Site.get(id=90369), 'vendor': 92760, 'manufacturer': None, 'upc': '1820096147', 'description': 'BUD LT AZULITAS 24PK CAN', 'price': 0, 'quantity_sold': 0, 'quantity_sold_weekly': 0, 'in_inventory': 0, 'lost_sales': 0.0, 'scanned_at': datetime.now()}
>>> SOOSItem.create(**data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/worx/oosworx/env/lib/python3.5/site-packages/peewee.py", line 4494, in create
    inst.save(force_insert=True)
  File "/usr/local/worx/oosworx/oosworx/models.py", line 54, in save
    return super(BaseModel, self).save(*args, **kwargs)
  File "/usr/local/worx/oosworx/env/lib/python3.5/site-packages/peewee.py", line 4680, in save
    pk_from_cursor = self.insert(**field_dict).execute()
  File "/usr/local/worx/oosworx/env/lib/python3.5/site-packages/peewee.py", line 3221, in execute
    in zip(meta.get_primary_key_fields(), pk_row)]
TypeError: zip argument #2 must support iteration
```

Any thoughts at all what might be causing this issue? I compared both definitions in the production and development databases (postgres) and they match word to word.


That's very odd. So peewee is expecting to get back the primary key, and since Postgres supports the "RETURNING" clause, peewee says "INSERT INTO my_table (cola, colb, colc) VALUES (vala, valb, valc) RETURNING primary_key".

For whatever reason, it appears that the database cursor is not returning anything.

Can you share the SQL that is generated by Peewee when it runs that above insert? You should be able to do:

```
SOOSItem.insert(**data).sql()
```

Any other ideas of what might be going on here?


Closing due to lack of response.


Please comment here and I'll reopen.


Just saw this happen when adding a trigger on a table changed the semantics of INSERT statements (inserts were not returning anything then). Dropping the trigger resolved the problem.

Aha! Many thanks @uzak !