From: Charles C. <ch...@ru...> - 2005-02-07 15:54:57
|
>> The main reason that I wanted to put the queries in a separate file is >> that different database engines have different dialects of SQL and I know >> that some queries that I have written will only work with MySQL. > > I see. Why not call the plugin AnalyseAccessLogSql then? > The inc should be AnalyseAccessLogMySql.inc then. > > The AccessLog class has methods to support (read/write) both logfiles > and sql logs. This plugin only deals with the fast SQL case. OK, this would make sense - maybe with a shorter name? I looked at Request_AccessLog & Request_AccesslogEntry in Request.php and chose not to follow that API. For the actual transactional part of the system, I agree totally that the backend should be as transparent as possible. But for (added-value) reporting why limit to the least common denominator? Unless someone wants to step up to the plate and deliver a query engine against the access log file... >>>Also with the name change from mode to queryName. >>>I think we want to keep "mode" for consistency. >> >> I thought long and hard about that before making the change as it really >> is a change in API. Again, to help people that are not familiar with >> programming PHP, I wanted >> a) the API name to match the parameter name and >> b) the API name to make sense > > queryName is too low level. Too SQL specific. The queryName is designed to be just that, a name. mode has the implication of being built-in, whereas queryName does give the sense of it just being an arbitrary name. And if the plugin is renamed to AnalyseAccessLogSql it should be even less of an issue Regards, Charles |