From: Arno B. <fir...@ab...> - 2004-03-08 11:20:37
|
Hi, > > I would be so delighted to > > have somebody do the encapsulation that I'd be prepared to overlook by > > feeling that virtual tables are likely to introduce more problems than > > they solve, and a probably client library layered on the database info > > call is easier to implement, more general, more extensible, faster, and > > more efficient. > > So far I tend to implement both interfaces, powered by a single > utility/class performing the actual retrieval of internal data (too much > overhead to be done just inside database_info, I suppose). Haven't decided > yet, whether both SQL and database_info interfaces will use this > utility/class, or the monitoring tables should be layered above > database_info call. I think the SQL implementation is a must here. It's easy accessible and easy to extend without breaking previous SQL statements. > > Has somebody given due consideration to namespace management for the > > plethera of new virtual tables? > > Although I'd love to introduce real two- (or three-, if we're going to > follow the SQL standard) level namespaces in FB, this is the task for > another major version. So the only choice is to use some prefix to > distinguish between "real" system relations and "virtual" monitoring ones. > Borland has chosen TMP$ as a prefix, but it just brings confusion to users, > IMO. Suggestion anyone? I agree with you that TMP$ isn't the right prefix here. So it could be something like : SYS$ MON$ > > A monitoring tool doing iteration fetches is a better solution than a > > user query. If nobody wants to write a monitoring tool, then ISQL > > (mega-ugly) is a regretable fallback. > > > > The question is important. If the primary client is a monitory program, > > then the API should use database_info for the reasons I mentioned. If > > nobody want to write one, then maybe virtual tables is the way to go, > > though it does beg the questions as to whether the feature is worth > > implementing... > The primary client is a dozen of management tools like IBExpert or > IBWorkbench. Also with SQL you can use the standard aggregate functions, sorting etc... > But I'm pretty sure that PSQL is another very important client > of this feature. Given CURRENT_CONNECTION and CURRENT_TRANSACTION context > variables, you can query any necessary data from the monitoring tables in > your procedures/triggers, if required (and if you're given permissions to). Would also be nice if we implement scheduling tasks (far away :-) in the future. Regards, Arno Brinkman ABVisie -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Firebird open source database (based on IB-OE) with many SQL-99 features : http://www.firebirdsql.org http://www.firebirdsql.info http://www.fingerbird.de/ http://www.comunidade-firebird.org/ Support list for Interbase and Firebird users : fir...@ya... Nederlandse firebird nieuwsgroep : news://80.126.130.81 |