- 1.103.0 (latest)
- 1.102.0
- 1.101.0
- 1.100.0
- 1.98.0
- 1.97.0
- 1.96.0
- 1.95.0
- 1.94.0
- 1.93.1
- 1.92.1
- 1.91.0
- 1.90.0
- 1.89.0
- 1.88.0
- 1.87.0
- 1.86.0
- 1.85.0
- 1.84.0
- 1.83.0
- 1.82.0
- 1.81.0
- 1.80.0
- 1.79.0
- 1.78.0
- 1.77.0
- 1.76.1
- 1.68.0
- 1.67.0
- 1.66.0
- 1.65.0
- 1.64.0
- 1.63.2
- 1.62.1
- 1.61.0
- 1.60.0
- 1.59.0
- 1.58.4
- 1.57.0
- 1.56.0
- 1.55.0
- 1.54.2
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 |