Difference: DBIQueryPlugin (6 vs. 7)

Revision 720 Feb 2006 - Main.VadimBelman

Line: 1 to 1
 

DBI Query Plugin

Line: 395 to 395
  * Only MySQL support provided for this feature. Support for other servers is not implemented yet.
Added:
>
>

Drawback and problems.

Working with a database isn't a simple task, in common. With this plugin I was trying to make it both as simple as possible and flexible same time. Balancing between these two extremes led to some compromises and side effects.

The biggest compromise was usage of Perl inlines for %DBI_DO%. The first approach was to make it working much like %DBI_QUERY%, using sections of declarations. But the more quiestions like:

  • how to check data consistency?
  • how to validate data?
  • how to generate error messages?

and several others of the kind was arising, the more final structure was looking like a new language. So, why developing a new one if Perl is here? But then again, as it was mentioned before, this way is not secure-enough and an administrator must take serious considerations before allowing usage of %DBI_DO% to a user.

The other issue is about plugin execution order. As one can see from MessageBoard example, attached to this topic, usage of other plugins could significally improve control over DBIQueryPlugin output. However, it is not guaranteed that another plugin would not be called in first place causing unpredictable results like unwanted changes in a Perl script.

Considering this issue the decision was made that DBIQueryPlugin must act as a preprocessor. For those who understand, it does all the job in beforeCommonTagsHandler() routine. This approach has three major drawbacks:

  • First of all, it doesn't really follow the guidelines.
  • It breaks common logic of page analysis. Consider the following example:

			%CALC{"$SET(var,1)"}%
			%DBI_QUERY{"..."}%
			SELECT ...
			  WHERE
				 field = %CALC{"$GET(var)"}%
			%DBI_QUERY%
			

One will not get what would be expected because at the time %CALC{"$GET(var)"}% is executed %CALC{"$SET(var,1)"}% has not been called yet! The only way to have it be done properly is to put the latter just under %DBI_QUERY{...}% line.

  • %INCLUDE{}% would not work because beforeCommonTagsHandler() is not called for included topics.

The last issue was the cause to implement classic plugin handling when it is requested during the inclusion procedure. Possible side effects of this hack are not studied yet and may create some headache.

 

Plugin Settings

Plugin settings are stored as preferences variables. To reference

 
Pixeon Medical Systems - Todos os direitos reservados. 2020
http://www.pixeon.com.br/