-
Notifications
You must be signed in to change notification settings - Fork 21
Description
Issue
I'm experimenting with the Trino.Data.ADO package by plugging it into where we are running a custom Trino ADO client. It seems to be very drop-in-replace, though there's currently an issue.
We are using Dapper to run the queries, and Dapper automatically passes in a CommandBehavior of
CommandBehavior.SequentialAccess | CommandBehavior.SingleResultThis value of CommandBehavior causes TrinoCommand::ExecuteDbDataReaderAsync to throw with a NotSupportedException.
Proposed Solution
It seems the CommandBehavior should be treated as a flags type, and care must be given to parse it out that way when implementing TrinoCommand::ExecuteDbDataReaderAsync. (ADO docs reference)
trino-csharp-client/trino-csharp/Trino.Data.ADO/Server/TrinoCommand.cs
Lines 211 to 230 in 30718ef
| switch (behavior) | |
| { | |
| case CommandBehavior.Default: | |
| // Single result means only run one query. Trino only supports one query. | |
| case CommandBehavior.SingleResult: | |
| queryExecutor = await RunQuery().ConfigureAwait(false); | |
| break; | |
| case CommandBehavior.SingleRow: | |
| // Single row requires the reader to be created and the first row to be read. | |
| queryExecutor = await RunQuery().ConfigureAwait(false); | |
| return new TrinoDataReader(queryExecutor); | |
| case CommandBehavior.SchemaOnly: | |
| queryExecutor = await RunNonQuery().ConfigureAwait(false); | |
| break; | |
| case CommandBehavior.CloseConnection: | |
| // Trino has no concept of a connection because every call is a new connection. | |
| queryExecutor = await RunQuery().ConfigureAwait(false); | |
| break; | |
| default: | |
| throw new NotSupportedException(); |
Instead of a switch, the individual bits should be extracted using bitwise AND test.