Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Create non-existent instances #6
It's possible that the object related with the cache model that we are
If we had created our caching model with create=True, example:
the instance for User.settings is going to be created in caste that it
Added some spaces to be Flake8 compliant.
I completely understand how useful this would be. However, this dramatically changes the API and expectations of what a "get" should do (ie. it should never do a write!) and feel very very strongly this should not be a default behaviour.
Also this introduces/inherits subtle transaction issues from get_or_create
I completely understand your concerns @lamby. I didn't think at all in other use-cases non related with ours (my mistake).
I am going to create a function
Please, feel free of taking a look to coming PR and comment if you are happy (or not).
Thanks for your feedback!
I did it on the commit message time ago @giftig, but the description here doesn't get updated.
I've removed the import changes because that is more related with our coding standards than with this project. If I add some gmg coding standards here I would need to add some tests and documentation though. We should create a ENGDEBT card to do that.
Sorry @lamby but we need this patchset merged to keep our packages and this synced.
If you really think that UPSERT could be a problem (which wasn't for few years), please provide a PR which introduces a suitable test to demonstrate that it fails, and we would be happy to provide a solution if you won't.
I would be happy of testing that behaviour on this package but the lack of tests make it really difficult. We were using our test suit on playfire to test it, and it seems that it works completely fine.
added a commit
this pull request
Mar 7, 2014
As I explained previously it is the idea/architecture behind using sparse models that this changeset encourages that is faulty, so not only would it be an abstraction-level violation to test it at the code level, it can demonstrate nothing whatsover of value as we can already deduce such a test will fail.
On a practical level, the test would also be cumbersome in the Django framework as requires simultaneous transactions.
http://lucumr.pocoo.org/2014/2/16/a-case-for-upserts/ should be sufficient background documentation if you are not immediately familiar with this general problem area.
(As a meta comment, it's an obvious non-sequitor to respond to a purely technical point with "no, because $process".)