> -----Original Message----- > From: Arkadiy Vertleyb [mailto:[EMAIL PROTECTED]] > > It is only when > > I obtain and dereference (?) a relation iterator (using print, or calling > > begin() then dereferencing) that iteration over the tables occurs. > > This is true in most cases. However if you use indexing, > instantiating of > such operator involvs building internal table (of iterators > or keys) in > needed order. > > > If I have tables which are not in fact const must I: > > > > a) Modify the tables and create new relation iterators > > OR > > b) Modify the tables and create new relation operators as well as > iterators .. > > I think a) is generally expected. In STL, iterators get > invalidated when a > container changes. In RTL you shold be fine with a) as long > as you don't > use indexes. If you do use indexes, they need to be updated > whenever a > table changes. With our current implementation that would > mean going with > b) > > This problem has two aspects: > > 1) We currently don't have the ability to incrementally > update an index. > This should be easy to fix.
Right. So the index would need soe form of insert and delete operators. What parameter would these take? An iterator to the new/soon to be deleted row in the table? > 2) Some events should be broadcasted (probably using observer > pattern) from > changing table to all indexes that depend on it, so that > indexes are updated > together with the table. Once this is implemented, you > should be fine with > a) in all cases. > That doesn't sound too hard either, give or take some lifetime management issues. For the incremental update facility to be useful it seems as though this facility should also be implemented. > > > As a potential user of some form of in-memory > > database that definitely needs relations/views based on > multiple tables > and > > that will have insertions and deletions (not necessarily > vast numbers of > > them) I'm very interested in this. > > We need to better understand your requirements in order to adjust our > priorities. Please don't pay too much attention to my application - I don't know how typical it is, and I could probably live with the lib as is. The application is to add querying/reporting capabilities to a monitoring/supervisory control system running on an embedded linux platform. Currently, such reporting is available from a central (periodically updated) SQL database, but for a number of reasons it would be useful to have similar facilities available directly from each monitoring device. We would also use the same mechanism for some core operational functions that are effectively queries on the data. In the absence of such a library those functions are, or would be, implemented on an ad-hoc basis. Inserts/deletes are relatively infrequent (these generally imply a change to the physical configuration of the system being monitored) but we need them to occur without disruption to the operation of the system as a whole. > Up until now, we were more focusing on the > algebra than on > updating tables. Therefore, updating tables is the area that > definitly has > a huge room for improvement. > I certainly think the emphasis on the algebra is the right one. The performance hit of rebuilding indexes would be relatively infrequent in my application, I'd have to progress a bit further with the design to see if this was a real issue. Thanks for the clarifications. Darryl Green. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
