Conversation
Reword the ADBC announcement such that Flight SQL is more clearly specified as being database-agnostic rather than vendor-specific.
|
Thanks for opening a pull request! Could you open an issue for this pull request on JIRA? Then could you also rename pull request title in the following format? See also: |
lidavidm
left a comment
There was a problem hiding this comment.
Could you add a notice to the top that the post was edited since its initial publication?
| But client applications that want to support multiple database vendors would need to integrate with each of them. | ||
| - *Directly use database protocols*. | ||
| For some databases, applications can use a database protocol or SDK to directly get Arrow data. | ||
| For example, applications could use be written with [Arrow Flight SQL][flight-sql] to connect to Dremio and other databases that support the Flight SQL protocol. |
There was a problem hiding this comment.
| For example, applications could use be written with [Arrow Flight SQL][flight-sql] to connect to Dremio and other databases that support the Flight SQL protocol. | |
| For example, applications could use [Arrow Flight SQL][flight-sql] to connect to Dremio and other databases that support the Flight SQL protocol. |
(If you want, I think it's fair to link "Dremio" to the website as well.)
| <th></th> | ||
| <th class="align-top" style="width: 40%" scope="col">Vendor-neutral (database APIs)</th> | ||
| <th class="align-top" style="width: 40%" scope="col">Vendor-specific (database protocols)</th> | ||
| <th class="align-top" style="width: 40%" scope="col">Database protocols</th> |
There was a problem hiding this comment.
I think it's still fair to call them vendor-specific; after all, multiple databases also use the PostgreSQL protocol (it just doesn't have a generic name). Maybe "varies by vendor (database protocols)"?
There was a problem hiding this comment.
Maybe a better phrase would be "Database specific protocols"
| - *Directly use database protocols*. | ||
| For some databases, applications can use a database protocol or SDK to directly get Arrow data. | ||
| For example, applications could use be written with [Arrow Flight SQL][flight-sql] to connect to Dremio and other databases that support the Flight SQL protocol. | ||
| But not all databases support the Flight SQL protocol. An example is Google BigQuery, which has a separate SDK that returns Arrow data. In this case, client applications that want to support additional protocols would need to integrate with each of them. |
There was a problem hiding this comment.
| But not all databases support the Flight SQL protocol. An example is Google BigQuery, which has a separate SDK that returns Arrow data. In this case, client applications that want to support additional protocols would need to integrate with each of them. | |
| But not all databases support Flight SQL, even if they support Arrow data. An example is Google BigQuery, which has a separate SDK that returns Arrow data. In this case, client applications that want to support additional databases would need to integrate with each of their protocols. |
alamb
left a comment
There was a problem hiding this comment.
Looks good to me. Thank you @jduo
Note there are still some references to "vendor specific / agnostic" in the text such as
- **Vendor-agnostic**: ADBC drivers can implement the API using any underlying protocol, while Flight SQL requires server-side support that may not be easy to add.
If we are going to modify that language, perhaps it would be good to consistently use an alternate term (like "database-agnostic") in all places.
| <th></th> | ||
| <th class="align-top" style="width: 40%" scope="col">Vendor-neutral (database APIs)</th> | ||
| <th class="align-top" style="width: 40%" scope="col">Vendor-specific (database protocols)</th> | ||
| <th class="align-top" style="width: 40%" scope="col">Database protocols</th> |
There was a problem hiding this comment.
Maybe a better phrase would be "Database specific protocols"
Reword the ADBC announcement such that Flight SQL is more clearly specified as being database-agnostic rather than vendor-specific.