deserialize --> objectify creates objects that are not a part of the submitted data

[grant-humphries]

Between version 0.3.1 and 0.3.2.post1 something has changed that caused the deserialize method (which I believe is inherited from colander) to handle data differently. See the example below:

# input object
{
    id: 4938,
    attribute1: False,
    attribute2: None,
    relationship_attribute: None, 
}

# result of deserialize with 0.3.1
{
    id: 4938,
    attribute1: False
}

# result of deserialize with 0.3.2.post1+
{
     id: 4938,
    attribute1: False,
    attribute2: <colander.null>
    relationship_attribute: []
}

You can see that deserialize has switched from dropping dictionary items that have a value of None to assigning them some sort of null(ish) value based colander schema. However where this becomes problematic is that relationships (or at least some relationships) that are submitted as having a value of None are converted to an empty list ([]) and if that deserilaize output is supplied to the objectify method the empty list is converted into an instance of the sqlalchemy class that the relationship is associated with (an instance with mostly null values).

I would consider this a bug as cases where the POST/PUT object originally supplies None for a relationship, can result in a row being written to that relationship's table if the output of objectify is committed to the database.

[tisdall]

I think you need to provide a lot more information here... ColanderAlchemy provides methods for translating a SQLA schema into a Colander schema. It never does any of the serialization/deserialization, that's all Colander. So, if it has something to do with this library then it means it's because it generated a different colander schema than it did before.

I had a chunk of code somewhere I used years ago to print out a schema, but I have no idea where that is now... However, I think all "serialized" content that colander accepts should essentially be strings, colander.null, or missing from the dict. If you pass in a boolean or an integer I think you end up with unforeseen issues.

Any way, I have no idea what an attribute2 or relationship_attribute so it's hard for me to figure out what's happening here.