Re: Stored procedures utility library

[Giuseppe Maxia]

Beat,
thanks for your thoughts.

Beat Vontobel wrote:
[SNIP]
>
> * We should have some style guide on how to write
> routines for the library: indentation, use of
> upper/lower case, use of routine header
> (DETERMINISTIC, NO SQL...), use of COMMENT in

One thing that I notice when I test routines made by others is that sometimes they don't load cleanly in my server, because I always use a binarylog. This means that a policy on submission is mandatory. When the routine has neither a 'deterministic' or a 'reads sql data' clause, then the use of the global variable log_bin_trust_routine_creators could be the only way of installing the routine.

> header (so we have a consistent way to describe
> our routines - this would give us sort of an
> online help for all of the library for free)
> * What format should we use for documentation?

We can borrow from other languages. Personally, I am used to write documentation in Perl POD, which
can produce HTML, RTF, text, and Latex very easily.
I'll think of something, but I believe POD is a good candidate because Perl is on almost every Unix server and it can be easily installed in Windows systems.

> Should we use a Wiki?
> * I thought about SourceForge myself - but is this
> the right place? When a lot of people start to
> contribute - how do we organize the routines? We
> don't want to have them in big files, as most of
> the people probably just look for one specific
> routine to solve a problem. So a database driven
> application to organize our routines would be
> something nice...

Routines should be grouped in small groups, to make them easy to install. When routines have dependencies, though,
we need to cerate some checking mechanism.
Putting routines in a database means that we need to implement a recursive check to let the user know which other routines need to be installed for the wanted one to work properly.

> (But we'd probably have to develop it ourselves. I don't know if there exists
> something we could readily use for that.)
>
> I think such a thing could grow very dynamically
> as soon as it's started - so we should make these
> points clear before it's almost too late to
> reorganize things due to the possible success...

:-)

Minimum requirements for admissions, out of the top of my head:
- they compile correctly in a safe box;
- their name does not confict with anything already existing;
- their use is fairly documented according to a template I have yet to figure out;
- they have a test unit;

> ;-)
>
> Regards,
> Beat

ciao
Giuseppe