stevearc / flywheel

Object mapper for Amazon's DynamoDB
MIT License
128 stars 25 forks source link

version 0.5 breaks ddb_dump_() #51

Open drcoll opened 8 years ago

drcoll commented 8 years ago

I've observed a breaking bug in version 0.5 of flywheel. Took me awhile to figure out the issue.

........
    else:
                print('Setting {}'.format(arg))
                setattr(user, arg, args[arg])

        print(user.secret_question)
        print(user.ddb_dump_())
        user.update()

The result, I would see the secret question I just set on my user object, but in the result of user.ddb_dump_() all of my newly attrs were gone (and it appeared some values for attrs defined in the model statically were missing). Thus, none of my newly added attributes to my user object were saving and my project and tests were breaking when trying to update a model.

There is something wrong with the user.ddb_dump_() method.. I believe that method is called for every model object to save to the database?

For updating I use the engine.save(self, overwrite=True)

I had to downgrade to 0.4.11 and everything started saving and working again.

stevearc commented 8 years ago

I think that this is the expected behavior now. In the 0.5 release I made the decision to remove the 'overflow fields' behavior. Any attribute that is not statically declared with Field will be ignored by design now.

The only part that sounds like it's potentially a bug is where you said "it appeared some values for attrs defined in the model statically were missing". This may have been because the values assigned to those fields were a null from dynamo's perspective (None, set(), ""). If that was not the case, then something is definitely going wrong.

If you need the overflow field behavior, then you should pin the flywheel version to 0.4.*

drcoll commented 8 years ago

Ah I see, sorry. I suppose I should have read into the version update deeper, before assuming this was breakage.

Yes I have a pass_hash field set on the user model, but it was None in the ddb_dump_().

I did not attempt to print the pass_hash value before doing the ddb_dump_(), so I suppose I cannot 100% confirm what the value was before doing the dump, but seeing as all my tests and code started working after I downgraded, and that wouldn't be the case if pass_hash wasn't set on the user in that method, I made the assumption the proper value is/was in fact there.

If I get time I can test out that case, I'm a bit swamped on work right now so not entirely sure when that might be.

stevearc commented 8 years ago

I know how that goes. If you happen to have time and find a minimal repro, definitely send it over. If everything is working with 0.4.x and you would prefer to never think about it again, that's fine too :)