Boost logo

Boost :

Subject: Re: [boost] [SQL-Connectivity] Is Boost interested in CppDB?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-12-14 14:22:52


>
> On Tue, Dec 14, 2010 at 1:18 AM, Artyom <artyomtnk_at_[hidden]> wrote:
> > I have recently released a new SQL Connectivity library:
>
> Sounds great!
>
> > - Performance is the primary goal - make fastest possible
> > SQL connectivity as possible
>
> Some DBMS like Oracle support "array bind" operations (on insert and
> select) which greatly improve performance by limiting round-trips to
> the server.

I'm aware of this feature as SOCI supports this and as Orcale's OCI
is only one API (at least onle one I'm aware off) that supports this.

CppDB has nothing special for this as it does not have (yet) Oracle
specific backend (you still can use ODBC with Oracle).

Also this kind of feature has many limitations on what can be fetched
and stored and is very "OCI" specific so I do not do anything like that.

I believe that during development of Orcale backend it is possible
to bind some internal buffers for this and save them.

And not I do not support this as it is very Oracle specific feature
and have quite lots of problems.

For example:

- What do you do with varchar(10000) types how do you do bulk operations?
  Allocate for each entry huge amount of memory? Is this good?

- What happens when you bind 100 strings when one of them is 10000 bytes
  length and others 10? Allocate 100x10000 bytes, I'm not aware
  if something better can be done but at least this is what SOCI does,
  and I beleive they do the best.

- What amount of data do you allocate? You do not know in advance
  how many rows you fetch.

This is exactly the kind of features that made SOCI's API too Orcale
oriented and make it hard to use in other cases with other databases.

So when writing Orcale backend it would be possible to do some optimizations
for fetching data but they should be internal for the backend and not
something generic.

At least this is my opinion...

Artyom

      


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk