MySQL Forums
Forum List  »  Stored Procedures

Re: Stored procedures utility library
Posted by: Roland Bouman
Date: November 21, 2005 06:53AM

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

Options: ReplyQuote


Subject
Views
Written By
Posted
5607
November 21, 2005 03:41AM
2648
November 21, 2005 04:39AM
2401
November 21, 2005 05:13AM
2520
November 21, 2005 08:00AM
Re: Stored procedures utility library
2664
November 21, 2005 06:53AM
2575
November 21, 2005 08:06AM
2389
November 21, 2005 08:32AM
7691
November 23, 2005 11:24AM
2507
December 03, 2005 08:37AM
2412
November 28, 2005 02:26AM
2496
November 29, 2005 04:28AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.