;> >>> >> > version 10.0.0", or use an independent versioning scheme?
>>> >>> >> > (For example, release API standard and components at
>>> >>> >> > "1.0.0". Then further releases of components that do not
>>
uot;2.0", "2.1", ...)
>> >>> >>
>> >>> >> I like an independent versioning schema. I assume that ADBC
>> >>> >> doesn't need backward incompatible changes frequently. How
>> >>> >&
; >>> >>
> >>> >> I like an independent versioning schema. I assume that ADBC
> >>> >> doesn't need backward incompatible changes frequently. How
> >>> >> about incrementing major version only when ADBC needs
> >>>
gt; 1. Release ADBC (the API standard) 1.0.0
>>> >> 2. Release adbc_driver_manager 1.0.0
>>> >> 3. Release adbc_driver_postgres 1.0.0
>>> >> 4. Add a new feature to adbc_driver_postgres without
>>> >> any backward incompatib
any backward incompatible changes
>> 7. Release adbc_driver_manager 1.0.1
>> 8. Add a backward incompatible change to adbc_driver_manager
>> 9. Release adbc_driver_manager 2.0.0
>> 10. Add a new feature to ADBC without any
>> backward inco
t; >> 5. Release adbc_driver_postgres 1.1.0
> >> 6. Fix a bug in adbc_driver_manager without
> >> any backward incompatible changes
> >> 7. Release adbc_driver_manager 1.0.1
> >> 8. Add a backward incompatible change to adbc_drive
mplementing Web
>> >> application by Ruby on Rails is one of major Ruby use
>> >> cases. So providing Active Record interface for ADBC will
>> >> increase Apache Arrow users in Ruby community.
>> >>
>> >> NOTE: Generally, Ruby on Rails user
ger 1.0.1
> 8. Add a backward incompatible change to adbc_driver_manager
> 9. Release adbc_driver_manager 2.0.0
> 10. Add a new feature to ADBC without any
> backward incompatible changes
> 11. Release ADBC (the API standard) 1.1.0
>
>
> Thanks,
> --
> kou
incompatible change to adbc_driver_manager
9. Release adbc_driver_manager 2.0.0
10. Add a new feature to ADBC without any
backward incompatible changes
11. Release ADBC (the API standard) 1.1.0
Thanks,
--
kou
In <7b20d730-b85e-4818-b99e-3335c40c2...@www.fastmail.com>
>
> OK. I'll open issues/pull requests when I find
> something. For now, I think that "MODULE" type library
> instead of "SHARED" type library in CMake terminology
> [cmake] is better for driver modules. (I'll open an issue
> for this later.)
&g
es apache/arrow-adbc,
>>>> apache/arrow's .deb/.rpm needs to depend on
>>>> apache/arrow-adbc's .deb/.rpm.)
>>>>
>>>> We can add .deb/.rpm related files
>>>> (dev/tasks/linux-packages/ in apache/arrow) to
>>>> apache/ar
ADBC
> from Ruby.) Or should I wait for the first release? If I can
> work on it now, I'll open pull requests for it.
>
> Thanks,
> --
> kou
>
> In <8703efd9-51bd-4f91-b550-73830667d...@www.fastmail.com>
> "Re: [DISC] Improving Arrow's database s
kou
In <8703efd9-51bd-4f91-b550-73830667d...@www.fastmail.com>
"Re: [DISC] Improving Arrow's database support" on Fri, 26 Aug 2022 11:03:26
-0400,
"David Li" wrote:
> Thank you Kou!
>
> At least initially, I don't think I'll be able to
t;
>
> Thanks,
> --
> kou
>
> In <5cbf2923-4fb4-4c5e-b11d-007209fdd...@www.fastmail.com>
> "Re: [DISC] Improving Arrow's database support" on Thu, 25 Aug 2022
> 11:51:08 -0400,
> "David Li" wrote:
>
>> Fair enough, t
ain/package
*
https://github.com/datafusion-contrib/datafusion-c/blob/main/.github/workflows/package.yaml
I can work on it in apache/arrow-adbc.
Thanks,
--
kou
In <5cbf2923-4fb4-4c5e-b11d-007209fdd...@www.fastmail.com>
"Re: [DISC] Improving Arrow's database support" on Thu,
It currently does do dlopen()/LoadLibrary but based on how it's being used by
Python I'm going to refactor that out separately so that the main method of
usage will be to pass it a pointer to the driver-specific initialization
function. It does not have any notion of internal registry. (And I'm
Le 25/08/2022 à 18:19, David Li a écrit :
Hmm, what is a driver manager exactly? Does it actually manage drivers
(how so)? Is it more of a core library?
It implements the ADBC API, but dynamically delegates to an actual
implementation underneath, so that you do not have to directly link to t
> Hmm, what is a driver manager exactly? Does it actually manage drivers
> (how so)? Is it more of a core library?
It implements the ADBC API, but dynamically delegates to an actual
implementation underneath, so that you do not have to directly link to the
driver, or to help deal with using mul
Le 25/08/2022 à 17:51, David Li a écrit :
Fair enough, thank you. I'll try to expand a bit. (Sorry for the wall of text
that follows…)
These are the components:
- Core adbc.h header
- Driver manager for C/C++
- Flight SQL-based driver
- Postgres-based driver (WIP)
- SQLite-based driver (more
Fair enough, thank you. I'll try to expand a bit. (Sorry for the wall of text
that follows…)
These are the components:
- Core adbc.h header
- Driver manager for C/C++
- Flight SQL-based driver
- Postgres-based driver (WIP)
- SQLite-based driver (more of a testbed for me than an actual component
On Fri, 19 Aug 2022 14:09:44 -0400
"David Li" wrote:
> Since it's been a while, I'd like to give an update. There are also a few
> questions I have around distribution.
>
> Currently:
> - Supported in C, Java, and Python.
> - For C/Python, there are basic drivers wrapping Flight SQL and SQLite,
That definitely makes sense :-)
Le 20/08/2022 à 00:15, David Li a écrit :
Flight SQL has no bindings for Python, R, etc. and this would give you
bindings, albeit indirectly; also, instead of asking users to choose between
different APIs, having Flight SQL under ADBC makes the decision easie
Flight SQL has no bindings for Python, R, etc. and this would give you
bindings, albeit indirectly; also, instead of asking users to choose between
different APIs, having Flight SQL under ADBC makes the decision easier -
servers implement Flight SQL, clients consume ADBC.
On Fri, Aug 19, 2022,
I see. What is the point of wrapping Flight SQL in ADBC then? Just for
consistency with other drivers?
Le 19/08/2022 à 23:00, David Li a écrit :
No, sorry: I meant only the API definitions by "C"; everything so far is
actually implemented in C++. There's no reason we couldn't port the SQLi
No, sorry: I meant only the API definitions by "C"; everything so far is
actually implemented in C++. There's no reason we couldn't port the SQLite
driver to pure C with nanoarrow but I've mostly used it as a testbed and not
tried to make it a 'real' driver.
On Fri, Aug 19, 2022, at 16:19, Anto
Le 19/08/2022 à 20:09, David Li a écrit :
Since it's been a while, I'd like to give an update. There are also a few
questions I have around distribution.
Currently:
- Supported in C, Java, and Python.
- For C/Python, there are basic drivers wrapping Flight SQL and SQLite, with a
draft of a l
Since it's been a while, I'd like to give an update. There are also a few
questions I have around distribution.
Currently:
- Supported in C, Java, and Python.
- For C/Python, there are basic drivers wrapping Flight SQL and SQLite, with a
draft of a libpq (Postgres) driver (using nanoarrow).
- Fo
I've set up the new repo and enabled issues. I still need to get things
building independently of Arrow, but now adbc.h is self-contained and the
"driver manager" being prototyped can also be built and used independently of
Arrow.
On Wed, Jun 1, 2022, at 13:55, David Li wrote:
> Wes: thanks! I'
Wes: thanks! I'll move things over and update the list.
Gavin: I mean more that ADBC won't support every little feature in JDBC/ODBC,
or won't necessarily make it easy to support certain things (e.g. updating a
single row in a ResultSet). But it's not that OLTP is taboo, it's just not what
is b
This sounds great, but I had one question:
Read the initial ADBC proposal and it mentioned that OLTP was not a
targeted usecase
If this work is intended to take on the role of a sort of standard ABI/SDK,
does that mean that building OLTP-oriented drivers/tooling with it is off
the table?
On Wed,
I went ahead and created
https://github.com/apache/arrow-adbc
I directed issue comments / PRs to issues@
On Tue, May 31, 2022 at 8:49 PM Wes McKinney wrote:
>
> I think spinning up a new repository while this exploratory work
> progresses is a fine idea — perhaps apache/arrow-dbc / arrow-adbc o
I think spinning up a new repository while this exploratory work
progresses is a fine idea — perhaps apache/arrow-dbc / arrow-adbc or
similar (the name can always be changed later). That would bubble up
discussions in a way that's easier for people to follow (watching your
fork isn't ideal!). If it
Some updates:
The proposal is being updated based on feedback from contributors to DuckDB and
DBI. We've been using GitHub issues on the fork to discuss the API design and
how to implement data ingestion/bound parameters:
https://github.com/lidavidm/arrow/issues
If anyone has suggestions/idea
I don't have major new things to add on this topic except that I've
long had the aspiration of creating something like Python's DBAPI 2.0
[1] at the C or C++ level to enable a measure of API standardization
for Arrow-native read/write interfaces with database drivers. It seems
like a natural comple
Do we want something more flexible than dlopen() and runtime symbol
lookup (a mechanism which constrains the way you can organize and
distribute drivers)?
For example, perhaps we could expose an API struct of function pointers
that could be obtained through driver-specific means.
Le 26/0
Hello,
In light of recent efforts around Flight SQL, projects like pgeon [1], and
long-standing tickets/discussions about database support in Arrow [2], it seems
there's an opportunity to define standard database interfaces for Arrow that
could unify these efforts. So we've put together a propo
36 matches
Mail list logo
