CurtHagenlocher commented on code in PR #1865: URL: https://github.com/apache/arrow-adbc/pull/1865#discussion_r1601733363
########## csharp/src/Apache.Arrow.Adbc/AdbcConnection11.cs: ########## @@ -0,0 +1,390 @@ +/* + * 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. + */ + +using System; +using System.Collections.Generic; +using System.Threading; +using System.Threading.Tasks; +using Apache.Arrow.Ipc; + +namespace Apache.Arrow.Adbc +{ + /// <summary> + /// Provides methods for query execution, managing prepared statements, + /// using transactions, and so on. + /// </summary> + public abstract class AdbcConnection11 : IDisposable +#if NET5_0_OR_GREATER + , IAsyncDisposable +#endif + { + ~AdbcConnection11() => Dispose(false); + + /// <summary> + /// Attempts to cancel an in-progress operation on a connection. + /// </summary> + /// <remarks> + /// This can be called during a method like GetObjects or while consuming an ArrowArrayStream + /// returned from such. Calling this function should make the other function throw a cancellation exception. + /// + /// This must always be thread-safe. + /// </remarks> + public virtual void Cancel() + { + throw AdbcException.NotImplemented("Connection does not support cancellation"); + } + + /// <summary> + /// Starts a new transaction with the given isolation level + /// </summary> + /// <param name="isolationLevel">The isolation level for the new transaction.</param> + public virtual void BeginTransaction(IsolationLevel? isolationLevel = default) + { + Task.Run(() => BeginTransactionAsync(isolationLevel)).GetAwaiter().GetResult(); + } + + public virtual Task BeginTransactionAsync(IsolationLevel? isolationLevel = default, CancellationToken cancellationToken = default) + { + throw AdbcException.NotImplemented("Connection does not support transactions"); + } + + /// <summary> + /// Create a new statement to bulk insert into a table. + /// </summary> + /// <param name="targetCatalog">The catalog name, or null to use the current catalog</param> + /// <param name="targetDbSchema">The schema name, or null to use the current schema</param> + /// <param name="targetTableName">The table name</param> + /// <param name="mode">The ingest mode</param> + /// <param name="isTemporary">True for a temporary table. Catalog and Schema must be null when true.</param> + public virtual AdbcStatement BulkIngest(string? targetCatalog, string? targetDbSchema, string targetTableName, BulkIngestMode mode, bool isTemporary) + { + throw AdbcException.NotImplemented("Connection does not support BulkIngest"); + } + + /// <summary> + /// Commit the pending transaction. + /// </summary> + public virtual void Commit() + { + Task.Run(() => CommitAsync()).GetAwaiter().GetResult(); + } + + /// <summary> + /// Commit the pending transaction. + /// </summary> + public virtual Task CommitAsync(CancellationToken cancellationToken = default) + { + throw AdbcException.NotImplemented("Connection does not support transactions"); + } + + /// <summary> + /// Create a new statement that can be executed. + /// </summary> + public abstract AdbcStatement CreateStatement(IReadOnlyDictionary<string, object>? options = default); Review Comment: In my mind, part of the goal of the API is to signal to implementers what they should be doing. I see a statement as a kind of unit of internal bookkeeping which doesn't use database resources until you ask it to do something else. By not having an async function for creating a statement, this intent is communicated fairly clearly to implementers. This is also consistent with ADO.NET's DbCommand, which doesn't have an async construction function (though there were likely other considerations there that we're not faced with). If there's a demonstrated need to do something differently, we can later add an async method that returns a ValueTask and that would be consistent with everything else we have. That said, I'm mostly neutral on adding it now so if you think it's better to have it then I'll change it. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
