Django

Code

Changeset 8670

Show
Ignore:
Timestamp:
08/28/08 12:18:05 (3 months ago)
Author:
mtredinnick
Message:

Changed create() and get_or_create() to force an insert (not update an existing value).

Backwards incompatible if you are using manually-specific primary key values
and relying on the previously documented behaviour that the new values would
always exist in the database (i.e. it would update the existing entry).

Fixed #8419.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • django/trunk/django/db/models/query.py

    r8598 r8670  
    309309        """ 
    310310        obj = self.model(**kwargs) 
    311         obj.save() 
     311        obj.save(force_insert=True) 
    312312        return obj 
    313313 
    …… 
    329329                obj = self.model(**params) 
    330330                sid = transaction.savepoint() 
    331                 obj.save() 
     331                obj.save(force_insert=True) 
    332332                transaction.savepoint_commit(sid) 
    333333                return obj, True 

  • django/trunk/docs/ref/models/instances.txt

    r8506 r8670  
    194194auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below. 
    195195 
     196.. _ref-models-force-insert: 
     197 
    196198Forcing an INSERT or UPDATE 
    197199~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

  • django/trunk/docs/ref/models/querysets.txt

    r8658 r8670  
    557557 
    558558    p = Person(first_name="Bruce", last_name="Springsteen") 
    559     p.save() 
     559    p.save(force_insert=True) 
    560560 
    561561are equivalent. 
     562 
     563The :ref:`force_insert <ref-models-force-insert>` parameter is documented 
     564elsewhere, but all it means is that a new object will always be created. 
     565Normally you won't need to worry about this. However, if your model contains a 
     566manual primary key value that you set and if that value already exists in the 
     567database, a call to ``create()`` will fail with an ``IntegrityError`` since 
     568primary keys must be unique. So remember to be prepared to handle the 
     569exception if you are using manual primary keys. 
    562570 
    563571``get_or_create(**kwargs)`` 
    …… 
    591599is *not* found, ``get_or_create()`` will instantiate and save a new object, 
    592600returning a tuple of the new object and ``True``. The new object will be 
    593 created according to this algorithm:: 
     601created roughly according to this algorithm:: 
    594602 
    595603    defaults = kwargs.pop('defaults', {}) 
    …… 
    602610doesn't contain a double underscore (which would indicate a non-exact lookup). 
    603611Then add the contents of ``defaults``, overriding any keys if necessary, and 
    604 use the result as the keyword arguments to the model class. 
     612use the result as the keyword arguments to the model class. As hinted at 
     613above, this is a simplification of the algorithm that is used, but it contains 
     614all the pertinent details. The internal implementation has some more 
     615error-checking than this and handles some extra edge-conditions; if you're 
     616interested, read the code. 
    605617 
    606618If you have a field named ``defaults`` and want to use it as an exact lookup in 
    …… 
    608620 
    609621    Foo.objects.get_or_create(defaults__exact='bar', defaults={'defaults': 'baz'}) 
     622 
     623 
     624The ``get_or_create()`` method has similar error behaviour to ``create()`` 
     625when you are using manually specified primary keys. If an object needs to be 
     626created and the key already exists in the database, an ``IntegrityError`` will 
     627be raised. 
    610628 
    611629Finally, a word on using ``get_or_create()`` in Django views. As mentioned