@@ -197,12 +197,16 @@ If you want to override this behavior, you'll need to declare the `DateTimeField
...
@@ -197,12 +197,16 @@ If you want to override this behavior, you'll need to declare the `DateTimeField
class Meta:
class Meta:
model = Comment
model = Comment
Note that by default, datetime representations are deteremined by the renderer in use, although this can be explicitly overridden as detailed below.
In the case of JSON this means the default datetime representation uses the [ECMA 262 date time string specification][ecma262]. This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: `2013-01-29T12:34:56.123Z`.
*`format` - A string representing the output format. If not specified, this defaults to `None`, which indicates that python `datetime` objects should be returned by `to_native`. In this case the datetime encoding will be determined by the renderer.
*`format` - A string representing the output format. If not specified, this defaults to `None`, which indicates that python `datetime` objects should be returned by `to_native`. In this case the datetime encoding will be determined by the renderer.
*`input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `DATETIME_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
*`input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `DATETIME_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`.
DateTime format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style datetimes should be used. (eg `'2013-01-29T12:34:56.000000'`)
DateTime format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style datetimes should be used. (eg `'2013-01-29T12:34:56.000000Z'`)
## DateField
## DateField
...
@@ -318,5 +322,6 @@ As an example, let's create a field that can be used represent the class name of
...
@@ -318,5 +322,6 @@ As an example, let's create a field that can be used represent the class name of
@@ -242,21 +242,21 @@ This allows you to write views that update or create multiple items when a `PUT`
...
@@ -242,21 +242,21 @@ This allows you to write views that update or create multiple items when a `PUT`
# True
# True
serialize.save() # `.save()` will be called on each updated or newly created instance.
serialize.save() # `.save()` will be called on each updated or newly created instance.
Bulk updates will update any instances that already exist, and create new instances for data items that do not have a corresponding instance.
By default bulk updates will be limited to updating instances that already exist in the provided queryset.
When performing a bulk update you may want any items that are not present in the incoming data to be deleted. To do so, pass `allow_delete=True` to the serializer.
When performing a bulk update you may want to allow new items to be created, and missing items to be deleted. To do so, pass `allow_add_remove=True` to the serializer.
serializer.save() # `.save()` will be called on each updated or newly created instance.
serializer.save() # `.save()` will be called on updated or newly created instances.
# `.delete()` will be called on any other items in the `queryset`.
# `.delete()` will be called on any other items in the `queryset`.
Passing `allow_delete=True` ensures that any update operations will completely overwrite the existing queryset, rather than simply updating any objects found in the incoming data.
Passing `allow_add_remove=True` ensures that any update operations will completely overwrite the existing queryset, rather than simply updating existing objects.
#### How identity is determined when performing bulk updates
#### How identity is determined when performing bulk updates
Performing a bulk update is slightly more complicated than performing a bulk creation, because the serializer needs a way of determining how the items in the incoming data should be matched against the existing object instances.
Performing a bulk update is slightly more complicated than performing a bulk creation, because the serializer needs a way to determine how the items in the incoming data should be matched against the existing object instances.
By default the serializer class will use the `id` key on the incoming data to determine the canonical identity of an object. If you need to change this behavior you should override the `get_identity` method on the `Serializer` class. For example:
By default the serializer class will use the `id` key on the incoming data to determine the canonical identity of an object. If you need to change this behavior you should override the `get_identity` method on the `Serializer` class. For example:
@@ -40,9 +40,11 @@ You can determine your currently installed version using `pip freeze`:
...
@@ -40,9 +40,11 @@ You can determine your currently installed version using `pip freeze`:
## 2.2.x series
## 2.2.x series
### Master
### 2.2.5
*Serializers now support bulk create and bulk update operations.
**Date**:26th March 2013
*Serializer support for bulk create and bulk update operations.
*Regression fix:Date and time fields return date/time objects by default. Fixes regressions caused by 2.2.2. See [#743][743] for more details.
*Regression fix:Date and time fields return date/time objects by default. Fixes regressions caused by 2.2.2. See [#743][743] for more details.
*Bugfix:Fix 500 error is OAuth not attempted with OAuthAuthentication class installed.
*Bugfix:Fix 500 error is OAuth not attempted with OAuthAuthentication class installed.
*`Serializer.save()` now supports arbitrary keyword args which are passed through to the object `.save()` method. Mixins use `force_insert` and `force_update` where appropriate, resulting in one less database query.
*`Serializer.save()` now supports arbitrary keyword args which are passed through to the object `.save()` method. Mixins use `force_insert` and `force_update` where appropriate, resulting in one less database query.