> > We left Flight SQL as experimental, so we should take the chance to fix > things, IMO.
+1 On Wed, Mar 23, 2022 at 2:11 PM David Li <lidav...@apache.org> wrote: > Hey James, > > For bitmasks: maybe we should treat some properties as "levels" instead of > bitmasks? And then they could follow the usual Protobuf enum style (UNKNOWN > = 0, other values follow). For SQL_DEFAULT_TRANSACTION_ISOLATION_LEVEL, > maybe it should be that an unset value means unknown, 0 means unsupported, > and the bits are reserved for transaction support (so we would remove NONE > at bit zero). > > For missing properties: I think these make sense in the general metadata. > I don't think we should code too specifically to either ODBC or JDBC. If > the goal is for the server/client not to know or care about the details of > the other end, then naturally properties like these should be well-defined > too. > > We left Flight SQL as experimental, so we should take the chance to fix > things, IMO. > > If there's anything missing in C++ we should add them. > > -David > > On Mon, Mar 21, 2022, at 19:37, James Duong wrote: > > I was examining the properties in GetSqlInfo and have a few questions as > > far as the proper way to approach some issues. > > > > Some bitmask properties have options that are intended to be mutually > > exclusive. > > For example the SQL_GROUP_BY property is a bitmask where possible values > > are: > > - SQL_GROUP_BY_UNRELATED and SQL_GROUP_BY_BEYOND_SELECT. > > It seems like SQL_GROUP_BY_UNRELATED implies SQL_GROUP_BY_BEYOND_SELECT. > > In another case SQL_DEFAULT_TRANSACTION_ISOLATION_LEVEL has NONE at bit > > zero, but can also set other bits that imply transactions are supported. > > > > These seem like issues, but I'm not really sure how to address this in > > terms of versioning. It seems like we should alter enum values. Would > this > > be a minor update? Backwards compatibility concerns? Seems early for > this. > > > > Adding missing syntax properties: > > Similar to above, should adding new properties be a minor version > > increment? There are properties missing such as reporting if catalogs and > > schemas are supported in DML (used in both ODBC and JDBC). > > > > There are some properties in bridge-specific metadata that can't be > > represented currently. An example is that ODBC reports metadata for if > > ALTER is supported in SQLGetInfo. Another example is reporting aggregate > > functions, which is used in ODBC but not JDBC. Would the right thing to > do > > be to add this to the general syntax section, or treat this as a "custom" > > property? There are JDBC-specific properties already such as savepoint > > support. To get more servers to support these properties, it'd probably > be > > best to treat these as non-custom, but at the expense of making > > bridge-specific concepts "standard". > > > > I've also observed that there are missing enums and enum values in the > C++ > > definitions of the properties in arrow/flight/sql/types.h > > > > -- > > > > *James Duong* > > Lead Software Developer > > Bit Quill Technologies Inc. > > Direct: +1.604.562.6082 | jam...@bitquilltech.com > > https://www.bitquilltech.com > > > > This email message is for the sole use of the intended recipient(s) and > may > > contain confidential and privileged information. Any unauthorized > review, > > use, disclosure, or distribution is prohibited. If you are not the > > intended recipient, please contact the sender by reply email and destroy > > all copies of the original message. Thank you. >
