piotr-szuberski commented on a change in pull request #12611:
URL: https://github.com/apache/beam/pull/12611#discussion_r483525931



##########
File path: sdks/python/apache_beam/io/gcp/spanner.py
##########
@@ -0,0 +1,503 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License.  You may obtain a copy of the License at
+#
+#    http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+"""PTransforms for supporting Spanner in Python pipelines.
+
+  These transforms are currently supported by Beam portable
+  Flink and Spark runners.
+
+  **Setup**
+
+  Transforms provided in this module are cross-language transforms
+  implemented in the Beam Java SDK. During the pipeline construction, Python 
SDK
+  will connect to a Java expansion service to expand these transforms.
+  To facilitate this, a small amount of setup is needed before using these
+  transforms in a Beam Python pipeline.
+
+  There are several ways to setup cross-language Spanner transforms.
+
+  * Option 1: use the default expansion service
+  * Option 2: specify a custom expansion service
+
+  See below for details regarding each of these options.
+
+  *Option 1: Use the default expansion service*
+
+  This is the recommended and easiest setup option for using Python Spanner
+  transforms. This option is only available for Beam 2.25.0 and later.
+
+  This option requires following pre-requisites before running the Beam
+  pipeline.
+
+  * Install Java runtime in the computer from where the pipeline is constructed
+    and make sure that 'java' command is available.
+
+  In this option, Python SDK will either download (for released Beam version) 
or
+  build (when running from a Beam Git clone) a expansion service jar and use
+  that to expand transforms. Currently Spanner transforms use the
+  'beam-sdks-java-io-google-cloud-platform-expansion-service' jar for this
+  purpose.
+
+  *Option 2: specify a custom expansion service*
+
+  In this option, you startup your own expansion service and provide that as
+  a parameter when using the transforms provided in this module.
+
+  This option requires following pre-requisites before running the Beam
+  pipeline.
+
+  * Startup your own expansion service.
+  * Update your pipeline to provide the expansion service address when
+    initiating Spanner transforms provided in this module.
+
+  Flink Users can use the built-in Expansion Service of the Flink Runner's
+  Job Server. If you start Flink's Job Server, the expansion service will be
+  started on port 8097. For a different address, please set the
+  expansion_service parameter.
+
+  **More information**
+
+  For more information regarding cross-language transforms see:
+  - https://beam.apache.org/roadmap/portability/
+
+  For more information specific to Flink runner see:
+  - https://beam.apache.org/documentation/runners/flink/
+"""
+
+# pytype: skip-file
+
+from __future__ import absolute_import
+
+import typing
+import uuid
+from typing import List
+from typing import NamedTuple
+from typing import Optional
+
+from past.builtins import unicode
+
+from apache_beam import coders
+from apache_beam.transforms.external import BeamJarExpansionService
+from apache_beam.transforms.external import ExternalTransform
+from apache_beam.transforms.external import NamedTupleBasedPayloadBuilder
+from apache_beam.typehints.schemas import named_tuple_to_schema
+
+__all__ = [
+    'WriteToSpanner',
+    'ReadFromSpanner',
+    'MutationCreator',
+    'TimestampBoundMode',
+    'TimeUnit',
+]
+
+
+def default_io_expansion_service():
+  return BeamJarExpansionService(
+      'sdks:java:io:google-cloud-platform:expansion-service:shadowJar')
+
+
+WriteToSpannerSchema = typing.NamedTuple(
+    'WriteToSpannerSchema',
+    [
+        ('instance_id', unicode),
+        ('database_id', unicode),
+        ('project_id', Optional[unicode]),
+        ('max_batch_size_bytes', Optional[int]),
+        ('max_number_mutations', Optional[int]),
+        ('max_number_rows', Optional[int]),
+        ('grouping_factor', Optional[int]),
+        ('host', Optional[unicode]),
+        ('emulator_host', Optional[unicode]),
+        ('commit_deadline', Optional[int]),
+        ('max_cumulative_backoff', Optional[int]),
+    ],
+)
+
+
+class WriteToSpanner(ExternalTransform):
+  """
+  A PTransform which writes mutations to the specified instance's database
+  via Spanner.
+
+  This transform receives Mutations defined as NamedTuple which are created
+  via utility class MutationCreator. Mutation needs to know what row type does
+  it wrap. Example::
+
+    ExampleRow = typing.NamedTuple('ExampleRow',
+                                   [('id', int), ('name', unicode)])
+    coders.registry.register_coder(ExampleRow, coders.RowCoder)
+
+    mutation_creator = MutationCreator('table', ExampleRow, 'ExampleMutation')

Review comment:
       That way we loose possibility of mixing different kinds of mutations. I 
don't imagine any sane usage of mixed insert/delete as the order is not 
guaranteed so I aggree that removing this assumption is justified.
   
   Since we will always map rows to mutations before then it would be good to 
enclose mapping rows to mutations inside WriteToSpanner. How about such an API?:
   ```
   pc.with_output_types(CustomRow) | WriteToSpanner(...).insert(table)
   pc.with_output_types(CustomRow) | WriteToSpanner(...).delete(table)
   pc.with_output_types(List[CustomRow]) | WriteToSpanner(...).delete(table)
   ```
   It's not consistent with ReadFromSpanner(...) but I think it's better than 
forcing the user to call RowToMutation each time.
   To be more consistent I could do something like 
`ReadFromSpanner(...).from_table(table)` and 
`ReadFromSpanner(...).from_sql(sql_query)`




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to