Python Client for Cloud Spanner
Cloud Spanner: is the world's first fully managed relational database service to offer both strong consistency and horizontal scalability for mission-critical online transaction processing (OLTP) applications. With Cloud Spanner you enjoy all the traditional benefits of a relational database; but unlike any other relational database service, Cloud Spanner scales horizontally to hundreds or thousands of servers to handle the biggest transactional workloads.
Quick Start
In order to use this library, you first need to go through the following steps:
- Select or create a Cloud Platform project.
- Enable billing for your project.
- Enable the Cloud Spanner.
- Set up Authentication.
Installation
Install this library in a virtual environment using venv. venv is a tool that creates isolated Python environments. These isolated environments can have separate versions of Python packages, which allows you to isolate one project's dependencies from the dependencies of other projects.
With venv, it's possible to install this library without needing system install permissions, and without clashing with the installed system dependencies.
Code samples and snippets
Code samples and snippets live in the samples/ folder.
Supported Python Versions
Our client libraries are compatible with all current active and maintenance versions of Python.
Python >= 3.9, including 3.14
Unsupported Python Versions
Python <= 3.8
If you are using an end-of-life version of Python, we recommend that you update as soon as possible to an actively supported version.
Mac/Linux
python3 -m venv <your-env> source <your-env>/bin/activate pip install google-cloud-spanner
Windows
py -m venv <your-env> .\<your-env>\Scripts\activate pip install google-cloud-spanner
Example Usage
Executing Arbitrary SQL in a Transaction
Generally, to work with Cloud Spanner, you will want a transaction. The
preferred mechanism for this is to create a single function, which executes
as a callback to database.run_in_transaction:
# First, define the function that represents a single "unit of work" # that should be run within the transaction. def update_anniversary(transaction, person_id, unix_timestamp): # The query itself is just a string. # # The use of @parameters is recommended rather than doing your # own string interpolation; this provides protections against # SQL injection attacks. query = """SELECT anniversary FROM people WHERE id = @person_id""" # When executing the SQL statement, the query and parameters are sent # as separate arguments. When using parameters, you must specify # both the parameters themselves and their types. row = transaction.execute_sql( query=query, params={'person_id': person_id}, param_types={ 'person_id': types.INT64_PARAM_TYPE, }, ).one() # Now perform an update on the data. old_anniversary = row[0] new_anniversary = _compute_anniversary(old_anniversary, years) transaction.update( 'people', ['person_id', 'anniversary'], [person_id, new_anniversary], ) # Actually run the `update_anniversary` function in a transaction. database.run_in_transaction(update_anniversary, person_id=42, unix_timestamp=1335020400, )
Select records using a Transaction
Once you have a transaction object (such as the first argument sent to
run_in_transaction), reading data is easy:
# Define a SELECT query. query = """SELECT e.first_name, e.last_name, p.telephone FROM employees as e, phones as p WHERE p.employee_id == e.employee_id""" # Execute the query and return results. result = transaction.execute_sql(query) for row in result.rows: print(row)
Insert records using Data Manipulation Language (DML) with a Transaction
Use the execute_update() method to execute a DML statement:
spanner_client = spanner.Client() instance = spanner_client.instance(instance_id) database = instance.database(database_id) def insert_singers(transaction): row_ct = transaction.execute_update( "INSERT Singers (SingerId, FirstName, LastName) " " VALUES (10, 'Virginia', 'Watson')" ) print("{} record(s) inserted.".format(row_ct)) database.run_in_transaction(insert_singers)
Insert records using Mutations with a Transaction
To add one or more records to a table, use insert:
transaction.insert( 'citizens', columns=['email', 'first_name', 'last_name', 'age'], values=[ ['phred@example.com', 'Phred', 'Phlyntstone', 32], ['bharney@example.com', 'Bharney', 'Rhubble', 31], ], )
Update records using Data Manipulation Language (DML) with a Transaction
spanner_client = spanner.Client() instance = spanner_client.instance(instance_id) database = instance.database(database_id) def update_albums(transaction): row_ct = transaction.execute_update( "UPDATE Albums " "SET MarketingBudget = MarketingBudget * 2 " "WHERE SingerId = 1 and AlbumId = 1" ) print("{} record(s) updated.".format(row_ct)) database.run_in_transaction(update_albums)
Update records using Mutations with a Transaction
Transaction.update updates one or more existing records in a table. Fails
if any of the records does not already exist.
transaction.update( 'citizens', columns=['email', 'age'], values=[ ['phred@example.com', 33], ['bharney@example.com', 32], ], )
Connection API
Connection API represents a wrap-around for Python Spanner API, written in accordance with PEP-249, and provides a simple way of communication with a Spanner database through connection objects:
from google.cloud.spanner_dbapi.connection import connect connection = connect("instance-id", "database-id") connection.autocommit = True cursor = connection.cursor() cursor.execute("SELECT * FROM table_name") result = cursor.fetchall()
If using [fine-grained access controls](https://cloud.google.com/spanner/docs/access-with-fgac) you can pass a database_role argument to connect as that role:
connection = connect("instance-id", "database-id", database_role='your-role')
Aborted Transactions Retry Mechanism
In !autocommit mode, transactions can be aborted due to transient errors. In most cases retry of an aborted transaction solves the problem. To simplify it, connection tracks SQL statements, executed in the current transaction. In case the transaction aborted, the connection initiates a new one and re-executes all the statements. In the process, the connection checks that retried statements are returning the same results that the original statements did. If results are different, the transaction is dropped, as the underlying data changed, and auto retry is impossible.
Auto-retry of aborted transactions is enabled only for !autocommit mode, as in autocommit mode transactions are never aborted.
Next Steps
- Read the Client Library Documentation for Cloud Spanner to see other available methods on the client.
- Read the Cloud Spanner Product documentation to learn more about the product and see How-to Guides.
- View this README to see the full list of Cloud APIs that we cover.
Logging
This library uses the standard Python logging functionality to log some RPC events that could be of interest for debugging and monitoring purposes.
Note the following:
- Logs may contain sensitive information. Take care to restrict access to the logs if they are saved, whether it be on local storage or on Google Cloud Logging.
- Google may refine the occurrence, level, and content of various log messages in this library without flagging such changes as breaking. Do not depend on immutability of the logging events.
- By default, the logging events from this library are not handled. You must explicitly configure log handling using one of the mechanisms below.
Simple, environment-based configuration
To enable logging for this library without any changes in your code, set the GOOGLE_SDK_PYTHON_LOGGING_SCOPE environment variable to a valid Google
logging scope. This configures handling of logging events (at level logging.DEBUG or higher) from this library in a default manner, emitting the logged
messages in a structured format. It does not currently allow customizing the logging levels captured nor the handlers, formatters, etc. used for any logging
event.
A logging scope is a period-separated namespace that begins with google, identifying the Python module or package to log.
- Valid logging scopes:
google,google.cloud.asset.v1,google.api,google.auth, etc. - Invalid logging scopes:
foo,123, etc.
NOTE: If the logging scope is invalid, the library does not set up any logging handlers.
Environment-Based Examples
- Enabling the default handler for all Google-based loggers
export GOOGLE_SDK_PYTHON_LOGGING_SCOPE=google- Enabling the default handler for a specific Google module (for a client library called
library_v1):
export GOOGLE_SDK_PYTHON_LOGGING_SCOPE=google.cloud.library_v1Advanced, code-based configuration
You can also configure a valid logging scope using Python's standard logging mechanism.
Code-Based Examples
- Configuring a handler for all Google-based loggers
import logging from google.cloud import library_v1 base_logger = logging.getLogger("google") base_logger.addHandler(logging.StreamHandler()) base_logger.setLevel(logging.DEBUG)
- Configuring a handler for a specific Google module (for a client library called
library_v1):
import logging from google.cloud import library_v1 base_logger = logging.getLogger("google.cloud.library_v1") base_logger.addHandler(logging.StreamHandler()) base_logger.setLevel(logging.DEBUG)
Logging details
- Regardless of which of the mechanisms above you use to configure logging for this library, by default logging events are not propagated up to the root
logger from the google-level logger. If you need the events to be propagated to the root logger, you must explicitly set
logging.getLogger("google").propagate = Truein your code. - You can mix the different logging configurations above for different Google modules. For example, you may want use a code-based logging configuration for
one library, but decide you need to also set up environment-based logging configuration for another library.
- If you attempt to use both code-based and environment-based configuration for the same module, the environment-based configuration will be ineffectual if the code -based configuration gets applied first.
- The Google-specific logging configurations (default handlers for environment-based configuration; not propagating logging events to the root logger) get executed the first time any client library is instantiated in your application, and only if the affected loggers have not been previously configured. (This is the reason for 2.i. above.)