Joaquin, sorry for the few days response here- I had a "surprise" business trip I had to take which kept me out of town and away from mail for a few days Thoughts below (note- I have left a good chunk of the original mail intact for context)

-----Original Message----- On Behalf Of Joaquin M Lopez Munoz

Brian Braatz <brianb <at> rmtg.com> writes:

...

If you would please elaborate. (some of us are "slower" than others :) ).

is the problem getting to the index objects themselves via inherit_linearly?

if you have dynamic data, then I am thinking you also have dynamically applied indices?

Maybe I can elaborate-

consider the following pseudo code:

connection con = db.connect("myserver,root,password,mydatabase");

dynamic_table dt;

// the select "*" means bring me back all the fields from that table // even though I don't know what the fields ARE yet dt = query("select * from person");

// ok so now dt has an UNKNOWN number of columns

dt.add_index( index("first_name"));

// or something along those lines.

in this case, the index is applied dynamically.

so how does that connect with the things you said ?

[Joaquin M Lopez Munoz Writes:]

Let me formulate the problem in the terminology of Boost.MultiIndex --hopefully, the implications for a DB framework scenario will be clear after this.

Consider the following perfectly normal code dealing with a static multi_index_container:

typedef multi_index_container< element, indexed_by< ordered_unique<identity<element> >, sequenced<>

...

static_mic_t;

template<typename Index> void reverse_dump(const Index& i) { std::copy( i.rbegin(),i.rend(), std::ostream_iterator<typename Index::value_type>(std::cout)); }

int main() { static_mic_t s_mic; ... reverse_dump(s_mic.get<0>()); reverse_dump(s_mic.get<1>()); }

What would the equivalent be for the dynamic case?

typedef dynamic_multi_index_container< element

...

dynamic_mic_t; // no indices specified at compile time

int main() { dynamic_mic_t d_mic;

// add indices at run time d_mic.add_index<ordered_unique<identity<element> > >(); d_mic.add_index<sequenced<> >(); ...

reverse_dump(d_mic.get(0)); // note index number is no longer reverse_dump(d_mic.get(1)); // a template parameter }

Now, how are we supposed to define reverse_dump? Clearly it cannot be the same template as in the static case, since the types of the indices are only known at run time. [Brian Braatz Writes:] ideas-

have the container accept a list of possible index types then use inherit_linearly<> to make those types- (only as pointers) then when the index gets runtime added- you store it in the generated objects Additionally- one could also force the user to make a struct to use as a tag to reference the index (instead of the number) using this "type tag", you can lookup the runtime object(s) which were dynamically added. What I am suggesting is a similar design to what I recently got working on something else (almost ready for sharing with the world). I have yet another plan trip tomorrow (ALL DAY tomorrow). I will code a small sample of what I am suggesting. (code is easier to talk about than concepts sometimes :) ) Joaquín M López Muñoz writes:

If I wasn't clear enough please tell me so and I'll try to elaborate. I'll be more than happy to discuss and refine these ideas. IMHO the concepts around a potential multi_index_container sketched here can serve as the basis for a DB run-time data structure, much like for instance IndexedDBView in the DTL does.

Best,

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

I am not as familiar with multi-index, but I am going to re-re-rereview that lib tomorrow along with the mail you wrote. Pleasure "talking" with you :) Brian