Azure Cosmos DB Python SDK for SQL API: Release notes and resources
APPLIES TO:
SQL API
Download SDK | PyPI |
API documentation | Python API reference documentation |
SDK installation instructions | Python SDK installation instructions |
Get started | Get started with the Python SDK |
Current supported platform | Python 2.7 and Python 3.5.3+ |
Release history
4.1.0 (2020-08-10)
- Added deprecation warning for "lazy" indexing mode. The backend no longer allows creating containers with this mode and will set them to consistent instead.
New features
- Added the ability to set the analytical storage TTL when creating a new container.
Bug fixes
- Fixed support for dicts as inputs for get_client APIs.
- Fixed Python 2/3 compatibility in query iterators.
- Fixed type hint error (Issue #12570).
- Fixed bug where options headers were not added to upsert_item function. Issue #11791 - thank you @aalapatirvbd.
- Fixed error raised when a non string ID is used in an item. It now raises TypeError rather than AttributeError (Issue #11793).
4.0.0
- Stable release.
- Added HttpLoggingPolicy to pipeline to enable passing in a custom logger for request and response headers.
4.0.0b6
- Fixed bug in synchronized_request for media APIs.
- Removed MediaReadMode and MediaRequestTimeout from ConnectionPolicy as media requests are not supported.
4.0.0b5
azure.cosmos.errors module deprecated and replaced by azure.cosmos.exceptions
The access condition parameters (
access_condition
,if_match
,if_none_match
) have been deprecated in favor of separatematch_condition
andetag
parameters.Fixed bug in routing map provider.
Added query Distinct, Offset, and Limit support.
Default document query execution context now used for
- ChangeFeed queries
- single partition queries (partitionkey, partitionKeyRangeId is present in options)
- Non-document queries
Errors out for aggregates on multiple partitions, with enable cross partition query set to true, but no "value" keyword present
Hits query plan endpoint for other scenarios to fetch query plan
Added
__repr__
support for Cosmos entity objects.Updated documentation.
4.0.0b4
Added support for a
timeout
keyword argument to all operations to specify an absolute timeout in seconds within which the operation must be completed. If the timeout value is exceeded, aazure.cosmos.errors.CosmosClientTimeoutError
will be raised.Added a new
ConnectionRetryPolicy
to manage retry behavior during HTTP connection errors.Added new constructor and per-operation configuration keyword arguments:
retry_total
- Maximum retry attempts.retry_backoff_max
- Maximum retry wait time in seconds.retry_fixed_interval
- Fixed retry interval in milliseconds.retry_read
- Maximum number of sockets read retry attempts.retry_connect
- Maximum number of connection error retry attempts.retry_status
- Maximum number of retry attempts on error status codes.retry_on_status_codes
- A list of specific status codes to retry on.retry_backoff_factor
- Factor to calculate wait time between retry attempts.
4.0.0b3
- Added
create_database_if_not_exists()
andcreate_container_if_not_exists
functionalities to CosmosClient and Database respectively.
4.0.0b2
- Version 4.0.0b2 is the second iteration in our efforts to build a client library that suits the Python language best practices.
Breaking changes
The client connection has been adapted to consume the HTTP pipeline defined in
azure.core.pipeline
.Interactive objects have now been renamed as proxies. This includes:
Database
->DatabaseProxy
User
->UserProxy
Container
->ContainerProxy
Scripts
->ScriptsProxy
The constructor of
CosmosClient
has been updated:The
auth
parameter has been renamed tocredential
and will now take an authentication type directly. This means the primary key value, a dictionary of resource tokens, or a list of permissions can be passed in. However the old dictionary format is still supported.The
connection_policy
parameter has been made a keyword only parameter, and while it is still supported, each of the individual attributes of the policy can now be passed in as explicit keyword arguments:request_timeout
media_request_timeout
connection_mode
media_read_mode
proxy_config
enable_endpoint_discovery
preferred_locations
multiple_write_locations
A new constructor has been added to
CosmosClient
to enable creation via a connection string retrieved from the Azure portal.Some
read_all
operations have been renamed tolist
operations:CosmosClient.read_all_databases
->CosmosClient.list_databases
Container.read_all_conflicts
->ContainerProxy.list_conflicts
Database.read_all_containers
->DatabaseProxy.list_containers
Database.read_all_users
->DatabaseProxy.list_users
User.read_all_permissions
->UserProxy.list_permissions
All operations that take
request_options
orfeed_options
parameters, these have been moved to keyword only parameters. In addition, while these options dictionaries are still supported, each of the individual options within the dictionary are now supported as explicit keyword arguments.The error hierarchy is now inherited from
azure.core.AzureError
:HTTPFailure
has been renamed toCosmosHttpResponseError
JSONParseFailure
has been removed and replaced byazure.core.DecodeError
- Added additional errors for specific response codes:
CosmosResourceNotFoundError
for status 404CosmosResourceExistsError
for status 409CosmosAccessConditionFailedError
for status 412
CosmosClient
can now be run in a context manager to handle closing the client connection.Iterable responses (for example, query responses and list responses) are now of type
azure.core.paging.ItemPaged
. The methodfetch_next_block
has been replaced by a secondary iterator, accessed by theby_page
method.
4.0.0b1
Version 4.0.0b1 is the first preview of our efforts to create a user-friendly client library that suits the Python language best practices. For more information about this, and preview releases of other Azure SDK libraries, please visit https://aka.ms/azure-sdk-preview1-python.
Breaking changes: New API design
Operations are now scoped to a particular client:
CosmosClient
: This client handles account-level operations. This includes managing service properties and listing the databases within an account.Database
: This client handles database-level operations. This includes creating and deleting containers, users, and stored procedures. It can be accessed from a cosmosClient` instance by name.Container
: This client handles operations for a particular container. This includes querying and inserting items and managing properties.User
: This client handles operations for a particular user. This includes adding and deleting permissions and managing user properties.These clients can be accessed by navigating down the client hierarchy using the
get_<child>_client
method. For full details on the new API, please see the reference documentation.
Clients are accessed by name rather than by ID. No need to concatenate strings to create links.
No more need to import types and methods from individual modules. The public API surface area is available directly in the
azure.cosmos
package.Individual request properties can be provided as keyword arguments rather than constructing a separate
RequestOptions
instance.
3.0.2
- Added Support for MultiPolygon Datatype
- Bug Fix in Session Read Retry Policy
- Bug Fix for Incorrect padding issues while decoding base 64 strings
3.0.1
- Bug fix in LocationCache
- Bug fix endpoint retry logic
- Fixed documentation
3.0.0
- Multi-regions write support added
- Naming changes
- DocumentClient to CosmosClient
- Collection to Container
- Document to Item
- Package name updated to "azure-cosmos"
- Namespace updated to "azure.cosmos"
2.3.3
- Added support for proxy
- Added support for reading change feed
- Added support for collection quota headers
- Bugfix for large session tokens issue
- Bugfix for ReadMedia API
- Bugfix in partition key range cache
2.3.2
- Added support for default retries on connection issues.
2.3.1
- Updated documentation to reference Azure Cosmos DB instead of Azure DocumentDB.
2.3.0
- This SDK version requires the latest version of Azure Cosmos DB Emulator available for download from https://aka.ms/cosmosdb-emulator.
2.2.1
- bugfix for aggregate dict
- bugfix for trimming slashes in the resource link
- tests for unicode encoding
2.2.0
- Added support for Request Unit per Minute (RU/m) feature.
- Added support for a new consistency level called ConsistentPrefix.
2.1.0
- Added support for aggregation queries (COUNT, MIN, MAX, SUM, and AVG).
- Added an option for disabling SSL verification when running against DocumentDB Emulator.
- Removed the restriction of dependent requests module to be exactly 2.10.0.
- Lowered minimum throughput on partitioned collections from 10,100 RU/s to 2500 RU/s.
- Added support for enabling script logging during stored procedure execution.
- REST API version bumped to '2017-01-19' with this release.
2.0.1
- Made editorial changes to documentation comments.
2.0.0
- Added support for Python 3.5.
- Added support for connection pooling using the requests module.
- Added support for session consistency.
- Added support for TOP/ORDERBY queries for partitioned collections.
1.9.0
Added retry policy support for throttled requests. (Throttled requests receive a request rate too large exception, error code 429.) By default, DocumentDB retries nine times for each request when error code 429 is encountered, honoring the retryAfter time in the response header. A fixed retry interval time can now be set as part of the RetryOptions property on the ConnectionPolicy object if you want to ignore the retryAfter time returned by server between the retries. DocumentDB now waits for a maximum of 30 seconds for each request that is being throttled (irrespective of retry count) and returns the response with error code 429. This time can also be overridden in the RetryOptions property on ConnectionPolicy object.
DocumentDB now returns x-ms-throttle-retry-count and x-ms-throttle-retry-wait-time-ms as the response headers in every request to denote the throttle retry count and the cumulative time the request waited between the retries.
Removed the RetryPolicy class and the corresponding property (retry_policy) exposed on the document_client class and instead introduced a RetryOptions class exposing the RetryOptions property on ConnectionPolicy class that can be used to override some of the default retry options.
1.8.0
- Added the support for geo-replicated database accounts.
- Test fixes to move the global host and masterKey into the individual test classes.
1.7.0
- Added the support for Time To Live(TTL) feature for documents.
1.6.1
- Bug fixes related to server-side partitioning to allow special characters in partition key path.
1.6.0
- Added the support for server-side partitioned collections feature.
1.5.0
- Added Client-side sharding framework to the SDK. Implemented HashPartionResolver and RangePartitionResolver classes.
1.4.2
- Implement Upsert. New UpsertXXX methods added to support Upsert feature.
- Implement ID-Based Routing. No public API changes, all changes internal.
1.3.0
- Release skipped to bring version number in alignment with other SDKs
1.2.0
- Supports GeoSpatial index.
- Validates ID property for all resources. Ids for resources cannot contain
?, /, #, \\
characters or end with a space. - Adds new header "index transformation progress" to ResourceResponse.
1.1.0
- Implements V2 indexing policy
1.0.1
- Supports proxy connection
Release & retirement dates
Microsoft provides notification at least 12 months in advance of retiring an SDK in order to smooth the transition to a newer/supported version. New features and functionality and optimizations are only added to the current SDK, as such it is recommended that you always upgrade to the latest SDK version as early as possible.
Warning
After 31 August 2022, Azure Cosmos DB will no longer make bug fixes or provide support to versions 1.x and 2.x of the Azure Cosmos DB Python SDK for SQL API. If you prefer not to upgrade, requests sent from version 1.x and 2.x of the SDK will continue to be served by the Azure Cosmos DB service.
Version | Release Date | Retirement Date |
---|---|---|
4.0.0 | May 20, 2020 | --- |
3.0.2 | Nov 15, 2018 | --- |
3.0.1 | Oct 04, 2018 | --- |
2.3.3 | Sept 08, 2018 | August 31, 2022 |
2.3.2 | May 08, 2018 | August 31, 2022 |
2.3.1 | December 21, 2017 | August 31, 2022 |
2.3.0 | November 10, 2017 | August 31, 2022 |
2.2.1 | Sep 29, 2017 | August 31, 2022 |
2.2.0 | May 10, 2017 | August 31, 2022 |
2.1.0 | May 01, 2017 | August 31, 2022 |
2.0.1 | October 30, 2016 | August 31, 2022 |
2.0.0 | September 29, 2016 | August 31, 2022 |
1.9.0 | July 07, 2016 | August 31, 2022 |
1.8.0 | June 14, 2016 | August 31, 2022 |
1.7.0 | April 26, 2016 | August 31, 2022 |
1.6.1 | April 08, 2016 | August 31, 2022 |
1.6.0 | March 29, 2016 | August 31, 2022 |
1.5.0 | January 03, 2016 | August 31, 2022 |
1.4.2 | October 06, 2015 | August 31, 2022 |
1.4.1 | October 06, 2015 | August 31, 2022 |
1.2.0 | August 06, 2015 | August 31, 2022 |
1.1.0 | July 09, 2015 | August 31, 2022 |
1.0.1 | May 25, 2015 | August 31, 2022 |
1.0.0 | April 07, 2015 | August 31, 2022 |
0.9.4-prelease | January 14, 2015 | February 29, 2016 |
0.9.3-prelease | December 09, 2014 | February 29, 2016 |
0.9.2-prelease | November 25, 2014 | February 29, 2016 |
0.9.1-prelease | September 23, 2014 | February 29, 2016 |
0.9.0-prelease | August 21, 2014 | February 29, 2016 |
FAQ
How will I be notified of the retiring SDK?
Microsoft will provide 12 month's advance notice before the end of support of the retiring SDK to facilitate a smooth transition to a supported SDK. We'll notify you through various communication channels: the Azure portal, Azure updates, and direct communication to assigned service administrators.
Can I author applications by using a to-be-retired Azure Cosmos DB SDK during the 12-month period?
Yes, you'll be able to author, deploy, and modify applications by using the to-be-retired Azure Cosmos DB SDK during the 12-month notice period. We recommend that you migrate to a newer supported version of the Azure Cosmos DB SDK during the 12-month notice period, as appropriate.
After the retirement date, what happens to applications that use the unsupported Azure Cosmos DB SDK?
After the retirement date, Azure Cosmos DB will no longer make bug fixes, add new features, or provide support to the retired SDK versions. If you prefer not to upgrade, requests sent from the retired versions of the SDK will continue to be served by the Azure Cosmos DB service.
Which SDK versions will have the latest features and updates?
New features and updates will be added only to the latest minor version of the latest supported major SDK version. We recommend that you always use the latest version to take advantage of new features, performance improvements, and bug fixes. If you're using an old, non-retired version of the SDK, your requests to Azure Cosmos DB will still function, but you won't have access to any new capabilities.
What should I do if I can't update my application before a cutoff date?
We recommend that you upgrade to the latest SDK as early as possible. After an SDK is tagged for retirement, you'll have 12 months to update your application. If you're not able to update by the retirement date, requests sent from the retired versions of the SDK will continue to be served by Azure Cosmos DB, so your running applications will continue to function. But Azure Cosmos DB will no longer make bug fixes, add new features, or provide support to the retired SDK versions.
If you have a support plan and require technical support, contact us by filing a support ticket.
Next steps
To learn more about Cosmos DB, see Microsoft Azure Cosmos DB service page.