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.
