Reference documentation and code samples for the Cloud Spanner V1 Client class ResultSetMetadata.
Metadata about a ResultSet or PartialResultSet.
Generated from protobuf message google.spanner.v1.ResultSetMetadata
Namespace
Google \ Cloud \ Spanner \ V1Methods
__construct
Constructor.
| Parameters | |
|---|---|
| Name | Description |
data |
array
Optional. Data for populating the Message object. |
↳ row_type |
StructType
Indicates the field names and types for the rows in the result set. For example, a SQL query like |
↳ transaction |
Transaction
If the read or SQL query began a transaction as a side-effect, the information about the new transaction is yielded here. |
↳ undeclared_parameters |
StructType
A SQL query can be parameterized. In PLAN mode, these parameters can be undeclared. This indicates the field names and types for those undeclared parameters in the SQL query. For example, a SQL query like |
getRowType
Indicates the field names and types for the rows in the result
set. For example, a SQL query like "SELECT UserId, UserName FROM
Users" could return a row_type value like:
"fields": [
{ "name": "UserId", "type": { "code": "INT64" } },
{ "name": "UserName", "type": { "code": "STRING" } },
]
| Returns | |
|---|---|
| Type | Description |
StructType|null |
|
hasRowType
clearRowType
setRowType
Indicates the field names and types for the rows in the result
set. For example, a SQL query like "SELECT UserId, UserName FROM
Users" could return a row_type value like:
"fields": [
{ "name": "UserId", "type": { "code": "INT64" } },
{ "name": "UserName", "type": { "code": "STRING" } },
]
| Parameter | |
|---|---|
| Name | Description |
var |
StructType
|
| Returns | |
|---|---|
| Type | Description |
$this |
|
getTransaction
If the read or SQL query began a transaction as a side-effect, the information about the new transaction is yielded here.
| Returns | |
|---|---|
| Type | Description |
Transaction|null |
|
hasTransaction
clearTransaction
setTransaction
If the read or SQL query began a transaction as a side-effect, the information about the new transaction is yielded here.
| Parameter | |
|---|---|
| Name | Description |
var |
Transaction
|
| Returns | |
|---|---|
| Type | Description |
$this |
|
getUndeclaredParameters
A SQL query can be parameterized. In PLAN mode, these parameters can be
undeclared. This indicates the field names and types for those undeclared
parameters in the SQL query. For example, a SQL query like "SELECT * FROM
Users where UserId = \@userId and UserName = \@userName " could return a
undeclared_parameters value like:
"fields": [
{ "name": "UserId", "type": { "code": "INT64" } },
{ "name": "UserName", "type": { "code": "STRING" } },
]
| Returns | |
|---|---|
| Type | Description |
StructType|null |
|
hasUndeclaredParameters
clearUndeclaredParameters
setUndeclaredParameters
A SQL query can be parameterized. In PLAN mode, these parameters can be
undeclared. This indicates the field names and types for those undeclared
parameters in the SQL query. For example, a SQL query like "SELECT * FROM
Users where UserId = \@userId and UserName = \@userName " could return a
undeclared_parameters value like:
"fields": [
{ "name": "UserId", "type": { "code": "INT64" } },
{ "name": "UserName", "type": { "code": "STRING" } },
]
| Parameter | |
|---|---|
| Name | Description |
var |
StructType
|
| Returns | |
|---|---|
| Type | Description |
$this |
|