Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MINOR: [Website] Reword ADBC announcement #299

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

MINOR: [Website] Reword ADBC announcement #299

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
10 changes: 5 additions & 5 deletions _posts/2023-01-05-introducing-arrow-adbc.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,10 +66,10 @@ Developers have a few options:
Libraries like [Turbodbc][turbodbc] and [arrow-jdbc][arrow-jdbc] handle row-to-columnar conversions for clients.
But this doesn't fundamentally solve the problem.
Unnecessary data conversions are still required.
- *Use vendor-specific protocols*.
For some databases, applications can use a database-specific protocol or SDK to directly get Arrow data.
For example, applications could use Dremio via [Arrow Flight SQL][flight-sql].
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.)

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

(Look at all the [connectors](https://trino.io/docs/current/connector.html) that Trino implements.)
And databases like PostgreSQL don't offer an option supporting Arrow in the first place.

Expand Down Expand Up @@ -144,7 +144,7 @@ ADBC fills a specific niche that related projects do not address. It is both:
<tr>
<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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a better phrase would be "Database specific protocols"

</tr>
</thead>

Expand Down