boost::rtl / rel where can I get some more infos
Hi Arkadiy a friend told me about boost::rtl/rel, so I was wondering where I can get some more infos about it, it sounds quite interessting. BR Vinzenz
"Vinzenz Feenstra" <evilissimo@web.de> wrote
a friend told me about boost::rtl/rel, so I was wondering where I can get some more infos about it, it sounds quite interessting.
You can download it from: http://groups.yahoo.com/group/boost/files/tables.zip It has some documentation that explains usage. If you have any additional questions or comments, they are welcome. Regards, Arkadiy
On 02/09/2005 11:52 AM, Arkadiy Vertleyb wrote: [snip]
You can download it from:
http://groups.yahoo.com/group/boost/files/tables.zip
It has some documentation that explains usage. If you have any additional questions or comments, they are welcome.
I've been looking at tables/doc/rtl.htm#_Toc68859940 and noted: Note that one can easily define two columns of the same type. In this case, ssn and salary are two distinct classes that both denote a column of type int. Having two columns with same name is prohibited. This requirement of unique column "names" (by which you mean column class, as indicated by a previous paragraph in rtl.htm) avoids the problem of duplicate types cited here: https://sourceforge.net/tracker/index.php?func=detail&aid=544055&group_id=29557&atid=396644 Is that right? IOW, you could use inherit_linearly for even non-class types by simple wrapping them in a uniquely named class. So, for example, you could use: template<typename Fields> struct row : inherit_linearly<Fields,inherit>{}; Is there some reason you don't?
"Larry Evans" <cppljevans@cox-internet.com> wrote
I've been looking at tables/doc/rtl.htm#_Toc68859940 and noted:
Note that one can easily define two columns of the same type. In this case, ssn and salary are two distinct classes that both denote a column of type int. Having two columns with same name is prohibited.
This requirement of unique column "names" (by which you mean column class, as indicated by a previous paragraph in rtl.htm) avoids the problem of duplicate types cited here:
https://sourceforge.net/tracker/index.php?func=detail&aid=544055&group_id=29 557&atid=396644
Is that right? IOW, you could use inherit_linearly for even non-class types by simple wrapping them in a uniquely named class. So, for example, you could use:
template<typename Fields> struct row : inherit_linearly<Fields,inherit>{};
Is there some reason you don't?
We started implementing RTL about 3 years ago, and came up with the initial version half a year after that. At that point, MPL wasn't yet as popular as it is now. The idea of RTL was a direct result of me reading the Andrei Alexandrescu's book, so many ideas were directly "borowed" from there. At that time we had our own typelist (a simplified VC6 adaptation of the Loki typelist). The tuple was generated by inhereting from columns (wrappers) in the same manner GenScatterredHierarchy works. Over time, we switched to MPL. However, the library still contains traces of that initial design. Also some design decisions were caused by the fact that we were using VC6. Carefully re-evaluating such design/implementation decisions would be a necessary pre-requisit of submitting RTL for the Boost review. Since at this point we don't see a lot of interest, we are reluctant to undertake this step. We already had worked for more than two years with practically no feedback. This may be OK for prove of concept (which was done), but IMO totally inacceptable if one wants to create a library that would deserve to be included in Boost. Regards, Arkadiy
hmm What exactly ist the motivation and the goal of rel/rtl ? BR Vinzenz Feenstra
"Vinzenz Feenstra" <evilissimo@web.de> wrote
What exactly ist the motivation and the goal of rel/rtl ?
To implement an STL-compatible "relational table" container, that is type-safe and allows fields of any built-in or user-defined type. Naturally, once there is a container, operations are required. Hence, the relational algebra. We think such library could become a good alternative to, for example, MS Access, for light-weight applications. Also, the possibility to perform relational operations on objects might bring new and unexpected possibilities. As always with relational databases, the library is particulary convenient and efficient when multiple views of the same data are required and need to be kept in-sync. HTH, Arkadiy
Arkadiy Vertleyb wrote:
"Vinzenz Feenstra" <evilissimo@web.de> wrote
What exactly ist the motivation and the goal of rel/rtl ?
To implement an STL-compatible "relational table" container, that is type-safe and allows fields of any built-in or user-defined type.
Naturally, once there is a container, operations are required. Hence, the relational algebra.
We think such library could become a good alternative to, for example, MS Access, for light-weight applications. Also, the possibility to perform relational operations on objects might bring new and unexpected possibilities. As always with relational databases, the library is particulary convenient and efficient when multiple views of the same data are required and need to be kept in-sync.
HTH,
Arkadiy
Hmm, that sounds interessting. I started thinking about doing some Policy Based, for a Database Frontend Library. And thought about using a STL-Container like interface But this class will access a real database, like SQLite. This what I am posting here is only an idea how it could be used: ------------------------------------------------------------------------ typedef dbContainer< // SQLite does not need any user/pw infos dbDatabase ( "Company.db" ), dbTable ( "Ware" ), // using table Ware dbRow < // defining the field of a row dbValues < dbInt< "id" , dbFieldOptions< dbPrimaryKey dbAutoIncrement > >, dbText < "name" > , dbFloat < "price" > > > , // end fields of a row definition dbBackend < dbSQLite > // use the SQLite Backend > WareTable; typedef WareTable::row_type WT_Row; WareTable wt_test; wt_test.insert(WT_Row(dbNULLType, "Apple" , "3.33" )); wt_test.insert(WT_Row(dbNULLType, "Orange" , "2.13" )); wt_test.insert(WT_Row(dbNULLType, "Peach" , "4.57" )); wt_test.insert(WT_Row(dbNULLType, "Plum" , "7.49" )); dbResIterator<WT_Row> results = wt_test.lookup(dbText<"name","Plum">); while(results){ while(results.columns) std::cout << *(results.columns++) << std::endl; ++results; } ------------------------------------------------------------------------ However this is only an idea I have, where nothing of it is implemented or something. I was asking myself if boost::rel/rtl will go in this direction or not. A db- backend would be nice, wouldn't it? Or a kind of SaveToDatabase ^^ xD BR Vinzenz
"Vinzenz Feenstra" <evilissimo@web.de> wrote
I was asking myself if boost::rel/rtl will go in this direction or not.
A db- backend would be nice, wouldn't it?
No, RTL was never intended as a front end to another database -- it is more like an in-memory database itself. But I think there are other libraries that do this... DTL? Arkadiy
Arkadiy Vertleyb wrote:
"Vinzenz Feenstra" <evilissimo@web.de> wrote
I was asking myself if boost::rel/rtl will go in this direction or not.
A db- backend would be nice, wouldn't it?
No, RTL was never intended as a front end to another database -- it is more like an in-memory database itself. But I think there are other libraries that do this... DTL?
Arkadiy
I had a look on DTL and SOCI they aren't nice, imo. Hmm would be that "in-memory db" serializable ?? BR Vinzenz
"Vinzenz Feenstra" <evilissimo@web.de> wrote
Hmm would be that "in-memory db" serializable ??
It's not at the moment, but it should be trivial to implement once there is a need. Of course, individual fields need to be serializable, and this is the user's responsibility. We had a naive serialization in place at some point, and then we removed it. If we do it again, it will most likely be done via the Boost Serialization library. Regards Arkadiy
On Thu, Feb 10, 2005 at 11:56:34AM -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Vinzenz Feenstra" <evilissimo@web.de> wrote
Hmm would be that "in-memory db" serializable ??
It's not at the moment, but it should be trivial to implement once there is a need. Of course, individual fields need to be serializable, and this is the user's responsibility.
We had a naive serialization in place at some point, and then we removed it. If we do it again, it will most likely be done via the Boost Serialization library. I am still working on the B*-tree implementation. :) At the moment I am just very busy with other things. I found an aspect oriented tree library written by a boost user, which needs some polishing before it can be used. But its strict design rule, of implementing all features as tree/node/link/value/key - type mutators allows interesting modifications,
Regards Andreas Pokorny
What do you think, how long it would take that rtl would be released with boost? ( I know I am asking too much but this would be the last question) BR and Many thanks Vinzenz
well, if it counts for anything I would be very intersted in such library On Thu, 10 Feb 2005 15:33:58 -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Vinzenz Feenstra" <evilissimo@web.de> wrote
What do you think, how long it would take that rtl would be released with boost?
Since so far we failed to raise any significant amount of interest, I don't see it happenning in the nearest future :-(
Regards,
Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Sérgio Vale e Pace" <svpace.forum@gmail.com> wrote
well, if it counts for anything I would be very intersted in such library
Of course it counts, and it is very much appreciated. Do you have any particular problem you want to apply it to, or is it just a general interest? Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Sérgio Vale e Pace" <svpace.forum@gmail.com> wrote
well, if it counts for anything I would be very intersted in such library
Of course it counts, and it is very much appreciated.
Do you have any particular problem you want to apply it to, or is it just a general interest?
Er, I think he's interessted in a integration into the boost releases, so I am interessted in too. BR Vinzenz
right now it's just a general interest, but being able to solve relational algebra equations using in memory sets of data already came up as an issue in past projects. primarily when trying to avoid round trip queries to the database On Fri, 11 Feb 2005 10:22:08 -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Sérgio Vale e Pace" <svpace.forum@gmail.com> wrote
well, if it counts for anything I would be very intersted in such library
Of course it counts, and it is very much appreciated.
Do you have any particular problem you want to apply it to, or is it just a general interest?
Regards,
Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
sorry for the short answer, but I was kind of sleepy. A couple a months ago I was working in a project something like: a group have several salesman that has several sales in the interface one selects a group and a list od salesman shows up, then one could select a salesman and it will be shown some statistical analysis profile on this guy, or it could search for a specific profile and the best match salesman get selected. In my first draft design if a salesman get selected then I query for his personal data, and all his sales and perform the analysis, on the other hand if a profile is send I load all sales and perform analisys, query for the most probables salesmans on the group and perform new analysis. The problem is that the DB server was remote and centralized so queries generate network trafic, disconnections, waits, angry users and so on. Then I redesigned the system to query for all salesman and sales in the group (inside a group there are a resonable low number of then) and perform the mix and matching in memory which was boring, repetitive and error prone, and mostly easy to acomplish with good relational algebra operations. The real thing was a litle more complicated than that, but in a nutshell that´s it Hope my history is of any help in rtl development, basicaly I would love to be able to perform relational operations togheter with other C++ operations. Also, I hope/wish to see Boost.RTL/Rel ;) around soon; On Sat, 12 Feb 2005 05:13:43 -0200, Sérgio Vale e Pace <svpace.forum@gmail.com> wrote:
right now it's just a general interest, but being able to solve relational algebra equations using in memory sets of data already came up as an issue in past projects. primarily when trying to avoid round trip queries to the database
On Fri, 11 Feb 2005 10:22:08 -0500, Arkadiy Vertleyb <vertleyb@hotmail.com> wrote:
"Sérgio Vale e Pace" <svpace.forum@gmail.com> wrote
well, if it counts for anything I would be very intersted in such library
Of course it counts, and it is very much appreciated.
Do you have any particular problem you want to apply it to, or is it just a general interest?
Regards,
Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Andreas Pokorny -
Arkadiy Vertleyb -
Larry Evans -
Sérgio Vale e Pace -
Vinzenz Feenstra