Re: Stored procedures utility library

[Beat Vontobel]

Okay, now this really starts to look like we have to build our own system to manage all of this and can't use something existing:

* "we could think of a task based category system" (Roland) -> We need a database.
* "The dependencies thing will be challenging, especially as we must take the pertinent mysql version into account too." (Roland) -> Database too, to manage this.
* "The benefit of doing the pretty printing automatically would be consistency." (Roland) -> Parser
* "Minimum requirements for admissions, out of the top of my head: [...]" (Giuseppe) -> Automatic checks would be nice.

> 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.

As a Perl programmer I could of course live with that. But there are a lot of MySQL users out there not at all used to POD, as their preferred language is PHP or VisualBasic - or Java, as Roland opts already for something like javadoc. But I think the javadoc/POD approach could be a good thing. Then we really have everything in one place. If we have to do a parsing (see pretty print above) and testing stage anyway, it would be easy to extract documentation as well.

But to complicate things further, I think we also need sort of a version control system, to allow for updates of library routines... As SQL routines are usually not too big, it would of course be possible to store every version entirely (I don't want to complicate everything even more).

A web based submission form, with automatic pretty-printing, doc extraction and test on a safe box... and a searchable library with dependency and version checks on the other side. Sounds really cool!

But I think now the question arises, should we really start this complicated (which of course would be a nice thing, but takes some time to develop)? Or should we just start with something really simple, risking that we have to clean-up afterward - but at least we have something online quickly?

> 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.

We could implement something like the CPAN installer in plain SQL! ;-) But seriously, we could at least do the checks for dependencies with some simple SQL in an installer script using information_schema.

> 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.

That's exactly what I was thinking of... having the same hassle over and over again.

> The COMMENT is a good idea, but look out!
> right now, it gets truncated when you have
> more than 64 characters there.

Oops, didn't realize this yet. Is there a feature request pending on lifting this?

> What do you think guys, should it be a utility store for sp's
> only, or could it also comprise more or less complete utilities
> that include tables (like your SP debugger for example Beat)?

Hm, would be nice if I could make srdb one of my first contributions. But what do you think? Maybe complicates things further if we have to take properly setup tables into account?

> Database objects should have their names prefixed
> in order to prevent future additions (keywords, builtins) to clash.

I agree. I only didn't do this with srdb as everything is in one distinct database anyway and srdb.srdb_attach just looked terrible, so I quoted everything (which of course looks ugly).

For the licence of the routines: I think GPL would be the best solution, as it fits nicely with MySQL itself.



Edited 1 time(s). Last edit at 11/29/2005 05:55AM by Beat Vontobel.