Re: Stored procedures utility library

[Roland Bouman]

Hi Guys, joining in on this in response to your email Giuseppe.

Let me say I think that this is a great idea. Like you two guys, I had some thoughts on this too.

- 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)? Just a question.

- As for the style guide:
Database objects should have their names prefixed in order to prevent future additions (keywords, builtins) to clash. Preferably the prefix would relate to the purpose of the procedure. I'm thinking here about the stuff you see in the PHP libraries.
As for the indentation and casing, especially of keywords - it would be nice if a distinction could be made between requirements for submissal and requirements for distribution. For example, I thinks it's overly paranoid to require that keywords are typed in upper case, especially because it shouldt be too hard to write a little parser that can do the capitalization once you start distributing the code.
Same goes for indentation. The benefit of doing the pretty printing automatically would be consistency.
If possible, it would be nice to require that identifiers are designed so that they should not have to be quoted. Readability, as well as portablilty is enanced enormously when you do stuff without backticks. Of course, this implicitly makes it impossible to use a reserverd word. Therefore, it's probably a good idea to require that variable names, labels etc. should also be prefixed. (Isnt there some sort of standard that dictats variable prefixing with some datatype abbreviation already?)

We could also try to get MySQL AB to make a statement about their preferred style

- The COMMENT is a good idea, but look out! right now, it gets truncated when you have more than 64 characters there. Also, there are no facilities to rigourously document parameters. In my experience, the 64 characters is not enough for a complete comment in many cases.

I did some experiments myself writing all of the code in an XML format, which has a lot of benefits: you can write the documentation and the source in one file, and extract whatever you need for a particular target. It also allows you to check dependencies, and all of this is done using just XSLT stylesheets.
Problems with this approach are that is can be a hassle to type it all. So maybe that's not a very good idea.

An Alternative would be it we'd use something like javadoc comments. This would ensure code and documentation are kept together - always. And the code would still compile. We can write a little utility ourselves that generates the documentation without too much of a hassle.

- The dependencies thing will be challenging, especially as we must take the pertinent mysql version into account too. I mean, once 5.1 is there, there might be some new functions, and you're going to want to be able to distinguish if a utility is dependant upon that.

- we could think of a task based category system, eg:
scheduling
debugging
introspection (metadata)
import
export
compatibility/porting

especially when we can make a small number of top categories (around 10, 20 max) with no or just one sublevel this could work rather nicely.

(While were at it, I'll drop a line a couple of other guys I think would want to contribute.)