are package bodies/function/procs supported ?
Status: Alpha
Brought to you by:
altumano
Menu
▾
▴
Hi,
I'm very enthusiastic about this piece of software.
Still I couldn't get package bodies or standalone
procedures/functions processed correctly:
I get a dump pointing to a token within the
first lines of the body...
-----------------------------------------------------
PLDoc version: 0.8.0
Parsing file ../PLDOC/emi_samples/CDWH/source.txt ...
Exception in thread "main" net.sourceforge.pldoc.parser.TokenMgrError: Lexical error at line 126, co
lumn 19. Encountered: " " (32), after : "="
at net.sourceforge.pldoc.parser.PLSQLParserTokenManager.getNextToken(PLSQLParserTokenManager
.java:3021)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_scan_token(PLSQLParser.java:9814)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3_22(PLSQLParser.java:9157)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3R_43(PLSQLParser.java:9165)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3R_45(PLSQLParser.java:8449)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3_33(PLSQLParser.java:8587)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3R_316(PLSQLParser.java:8595)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3R_42(PLSQLParser.java:8650)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3R_44(PLSQLParser.java:8828)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_3_29(PLSQLParser.java:8892)
at net.sourceforge.pldoc.parser.PLSQLParser.jj_2_29(PLSQLParser.java:5783)
at net.sourceforge.pldoc.parser.PLSQLParser.statement(PLSQLParser.java:3355)
at net.sourceforge.pldoc.parser.PLSQLParser.programUnit(PLSQLParser.java:2313)
at net.sourceforge.pldoc.parser.PLSQLParser.declarativeSection(PLSQLParser.java:1966)
at net.sourceforge.pldoc.parser.PLSQLParser.packageBody(PLSQLParser.java:1512)
at net.sourceforge.pldoc.parser.PLSQLParser.input(PLSQLParser.java:1056)
at net.sourceforge.pldoc.PLDoc.main(PLDoc.java:133)
-----------------------------------------------------
Thanx,
EM
Bodies are not supported yet
Is there a way to tell pldoc to skip bodies?
I mean we have header and body in the same sql file and this means we are not able to use pldoc.
No.
Try to dump header file only. You don't need to include body file for documentation usage.
Hi , Do you plan to support the following code types :
procedure,functions, triggers ?
If there are code problems , can you describe what the problem , and way you think it can be solved or w/o ?
I do plan and have even started to implement.
The problem is that it is not easy to parse procedure, functions, triggers - too many different language constructs should be supported.
For packages, functions, and procedures, I've pondered doing something that simply relies on All_Procedures and All_Arguments catalog views. That won't help with triggers, of course. I also wish Oracle supported COMMENT against those things as a structured placeholder for descriptions, although that would limit it to 4,000 characters.
Don't know if this plants any interesting "sseeds", but thought I'd mention it.
BJ
Yes, but pldoc uses only plain files as input, it does not read database directly.
Concerning the triggers, functions and procs :
Isn't is possible to parse the creation part of the script then to skip until the end of the script ?
This would be a solution to avoid all the parsing of the code itself.
There may be many database objects in the same file.
okay, let me reformulate :)
Isn't it possible to parse the creation part of the object then to skip until the end of the object ?
CREATE OR REPLACE PACKAGE BODY test
IS
PROCEDURE test_one IS
BEGIN
...
END test_one;
PROCEDURE test_two IS
BEGIN
...
END test_two;
END test;
You just have to "skip" the inner blocks of the functions or procedures... Isnt it ?
By the way, this would also allow to use some specific tags to document some inner algorithms in detail.
Well, it's just a guess of course, but counting the "begin" and "end" in order to skip entire blocks look easier than parsing the entire code of the objects themselves...
(specifically for the trigger, you just have to search for an end).
What about such code example:
CREATE OR REPLACE PACKAGE BODY test
IS
PROCEDURE test_one IS
BEGIN
-- now BEGIN the work
...
END;
PROCEDURE test_two IS
BEGIN
...
-- tha's the END
END;
PROCEDURE test_three IS
BEGIN
...
-- well, that's was a PROCEDURE ...
END;
END;
Well, in a sense, yes, why not.
I was also eventually thinking at something like
CREATE OR REPLACE PACKAGE BODY test
IS
PROCEDURE test_one IS
BEGIN
...
/** Accounting - This particular block contains the
* very specific accounting exceptions of the
* customer. It uses assets a very specific way,
* as detailed in Use Case # BT-00354
*/
BEGIN
...
END;
...
END;
[...]
END;
This way, counting the "begin" and "end", you always know where you are, more specifically if you also take into account the procedures and functions.
And you can get the comments you come accross to put in the XML output.
By the way, I don't think that parsing the package body is the more important thing to do : triggers are on my point of view the more important ( and probably the easiest if you only take care of the header and skip the inner blocks). Triggers are always a critical part of the database, and probably the more complex also (before, instead of, after row or statement, multiple triggers on the same event of the same table, ...) and therefore requiers practical documentation.
... unfortunately it is more complicated in practice. BEGINs and ENDs might be embedded in multi-line strings or comments, may be entered in any combination of upper- and lower-case, the procedure name may be given between the END and ":", an anonymous block name may similarly be included after its END, none of which should be confused with ENDs with a trailing reserved word such as IF, LOOP, CASE, etc., etc.
Yes !
okay...
I was just trying to find an easy fix-solution to a complex problem ;)