[
https://issues.apache.org/jira/browse/BEAM-9615?focusedWorklogId=513325&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-513325
]
ASF GitHub Bot logged work on BEAM-9615:
----------------------------------------
Author: ASF GitHub Bot
Created on: 18/Nov/20 03:56
Start Date: 18/Nov/20 03:56
Worklog Time Spent: 10m
Work Description: youngoli commented on a change in pull request #13366:
URL: https://github.com/apache/beam/pull/13366#discussion_r525738322
##########
File path: sdks/go/pkg/beam/core/runtime/graphx/schema/logicaltypes.go
##########
@@ -0,0 +1,122 @@
+// 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.
+
+package schema
+
+import (
+ "fmt"
+ "reflect"
+
+ "github.com/apache/beam/sdks/go/pkg/beam/core/util/reflectx"
+)
+
+var (
+ // Maps logical type identifiers to their reflect.Type and the schema
representation.
+ // the type identifier is the reflect.Type name, and included in the
proto as well.
+ // We don't treat all types as "logical" types.
+ // ... why don't we treat all types as Logical types?
+ logicalTypes = map[string]LogicalType{}
+ logicalIdentifiers = map[reflect.Type]string{}
+)
+
+// LogicalType is an interface between custom Go types, and schema storage
types.
+//
+// A LogicalType is a way to define a new type that can be stored in a schema
field
+// using a known underlying type for storage. The storage type must be
comprised of
+// known schema field types, or pre-registered LogicalTypes. LogicalTypes may
not be
+// mutually recursive at any level of indirection.
+//End
Review comment:
Is this godoc-related or just something accidentally left in?
##########
File path: sdks/go/pkg/beam/core/runtime/graphx/schema/logicaltypes.go
##########
@@ -0,0 +1,122 @@
+// 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.
+
+package schema
+
+import (
+ "fmt"
+ "reflect"
+
+ "github.com/apache/beam/sdks/go/pkg/beam/core/util/reflectx"
+)
+
+var (
+ // Maps logical type identifiers to their reflect.Type and the schema
representation.
+ // the type identifier is the reflect.Type name, and included in the
proto as well.
+ // We don't treat all types as "logical" types.
+ // ... why don't we treat all types as Logical types?
+ logicalTypes = map[string]LogicalType{}
+ logicalIdentifiers = map[reflect.Type]string{}
Review comment:
I don't understand the reason to have the ID layer between
logicalIdentifiers and logicalTypes. Is there a reason not to just have this?:
```suggestion
logicalTypes = map[reflect.Type]LogicalType{}
```
##########
File path: sdks/go/pkg/beam/core/runtime/graphx/schema/schema.go
##########
@@ -412,12 +382,18 @@ func fieldTypeToReflectType(sft *pipepb.FieldType, opts
[]*pipepb.Option) (refle
// case *pipepb.FieldType_IterableType:
// TODO(BEAM-9615): handle IterableTypes.
- //case *pipepb.FieldType_LogicalType:
- // TODO(BEAM-9615): handle LogicalTypes types.
- //sft.GetLogicalType().
+ case *pipepb.FieldType_LogicalType:
+ lst := sft.GetLogicalType()
+ identifier := lst.GetUrn()
+ lt, ok := logicalTypes[identifier]
+ if !ok {
+ return nil, errors.Errorf("unknown logical type: %v",
identifier)
+ }
+ t = lt.GoType()
// Logical Types are for things that have more specialized user
representation already, or
- // things like Time or protocol buffers.
+ // things like Time or protocol buffers, or int.
+ // Or specifically formatted integers.
Review comment:
Nit: This line can just be part of the previous line.
----------------------------------------------------------------
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]
Issue Time Tracking
-------------------
Worklog Id: (was: 513325)
Time Spent: 17.5h (was: 17h 20m)
> [Go SDK] Beam Schemas
> ---------------------
>
> Key: BEAM-9615
> URL: https://issues.apache.org/jira/browse/BEAM-9615
> Project: Beam
> Issue Type: New Feature
> Components: sdk-go
> Reporter: Robert Burke
> Assignee: Robert Burke
> Priority: P2
> Time Spent: 17.5h
> Remaining Estimate: 0h
>
> Schema support is required for advanced cross language features in Beam, and
> has the opportunity to replace the current default JSON encoding of elements.
> Some quick notes, though a better fleshed out doc with details will be
> forthcoming:
> * All base coders should be implemented, and listed as coder capabilities. I
> think only stringutf8 is missing presently.
> * Should support fairly arbitrary user types, seamlessly. That is, users
> should be able to rely on it "just working" if their type is compatible.
> * Should support schema metadata tagging.
> In particular, one breaking shift in the default will be to explicitly fail
> pipelines if elements have unexported fields, when no other custom coder has
> been added. This has been a source of errors/dropped data/keys and a simply
> warning at construction time won't cut it. However, we could provide a manual
> "use beam schemas, but ignore unexported fields" registration as a work
> around.
> Edit: Doc is now at https://s.apache.org/beam-go-schemas
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
