Re: [boost] Interest in an ODBC library?

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-07-28 17:48:15

Hello Brian,

----- Mensaje original -----
De: Brian Braatz <brianb_at_[hidden]>
Fecha: Jueves, Julio 28, 2005 10:34 pm
Asunto: Re: [boost] Interest in an ODBC library?

> If you are interested in collaborating, I have wanted to (for some 
> timenow) build the table<> aspect of what you are working on.
> 
> My goals:
> 1- functional drop in replacement for ADO recordset
> 2- Dynamic and static "views" and indexes
> 3- binding model that does NOT force you to use the bindings supplied
> with the library 
> 	this is something ADO lacks, and something I have had to work
> around to great frustration
> 4- the ability to COPY from one table<> to another table<>
> 	* ADO does NOT ALLOW you to copy recordsets. (brilliant no?)
> 
> 
> Additionally - 
>
> I am not sure if he is still interested, but Joaquin Munez and I
> exchanged emails awhile back about collaborating on such a beast.
> 
> The general idea was to take the functionality in multi-index 
> containerand make it work dynamically.
> 

I am still interested, and it is my plan to implement a
dynamic_multi_index_container in the future, if there's
interest in such a thing --serving as the foundation for
a DB table structure would be a very exciting application,
undoubtedly.

Let me sketch what I have in mind: The part of adding/removing
indices at run time is not too hard: I haven't written any actual
code, but the design of that feature seems reasonably
straightforward to me. Some speed/space performance will
be lost, but I guess this is expected.

The hard part, IMHO, is how to gain access to such indices.
Clearly some kind of runtime polymorhpisn is involved
for a dynamic_multi_index_container to have any use:
otherwise, the user code would have to know the exact type
of the index it is retrieving. So we need something more powerful
than the  current static get<> interface.  A possibility
is to retrieve indices by mean of *interfaces* as
defined in Jonathan Turkanis' BIL library:

http://www.kangaroologic.com/interfaces/libs/interfaces/doc/

This interface concept provides the needed run-time polymorphism
without having to cast the index classes into a rigid
abstract hierarchy. This would allow the user to tune
the polymorphic functionality exposed by indices from
the most general (iteration) to the most concrete (for
instance, set-like functionality, so restricting the
type of acceptable indices that can go into the
container) only by defining the interface to which
the indices must conform.

Of course, this is just a bunch of random thoughts
and the BIL library is not part as of yet of Boost,
so I don't think I'll be ready to provide something
until mid 2006 or so. Moreover, it's still to be seen
whether a dynamic_multi_index_container is of interest
to the Boost community. 

> 
> I am working on something unrelated to this discussion that could 
> form a
> good foundation for table<>. I should have something to share 
> middle of
> next week.
> 
> Just let me know if you are interested in putting our heads together.
> 

Sure! I'll be reading your table<> material as soon
as you make it available. Soon I'll be on a three-week
vacation, so I might have some time to write my ideas
about a dynamic_multi_index_container in a more
structured way.

Best regards,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo