
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