Javadoc is a tool for generating API documentation in HTML format from doc comments in source code. Wouldn’t it be nice if a similar tool existed for PLSQL? Well you’re in luck because someone already made that available via an open-source utility known as pldoc.
Automatically document your database schema with SQL Developer using the DB Doc feature. Generate HTML pages and allow your teams to click through the PLSQL source and tables without access to development databases!
SQL Developer has extended pldoc into ‘DB Doc.’ DB Doc includes the PLSQL documentation functionality and adds the ability to also document the following objects:
- Tables
- Views
- Editioning Views
- Indexes
- Queues
- Sequences
- Materialized Views
- Synonyms
- Database Links
- Directories
- Editions
- Application Express
- Stored Java Procedures
- XML Schemas
- XML DB Repository
No additional work is required to take advantage of the regular database object documentation. However, if you want to harness the full power provided by pldoc, you need to start building additional documentation into your PLSQL objects via these commenting schemes seen in this sample code.
Here’s a quick preview of how that looks when you add it to your PLSQL
CREATE OR REPLACE PACKAGE CUSTOMER_DATA IS /** * Project: Project (<a href="http://pldoc.sourceforge.net">PLDoc</a>)<br/> * Description: Customer Data Management<br/> * DB impact: YES<br/> * Commit inside: NO<br/> * Rollback inside: NO<br/> * @headcom */ /** * Record of customer data. * * @param id customer ID * @param name customer name * @param regno registration number or SSN * @param language preferred language */ TYPE customer_type IS RECORD ( id VARCHAR2(20), name VARCHAR2(100), regno VARCHAR2(50), language VARCHAR2(10) ); ...
When you build the DB Doc set with SQL Developer, the PLSQL pages will be built using the information inside these /* */ blocks
Running DB Doc in SQL Developer
You will need to define a connection for the schema you want to document. You can then mouse-right-click on the connection in the connection tree and select ‘Generate DB Doc…’
You only have a few options. Decide which types of objects you want included. Decide if you want blank pages if there are no objects for that object type. And provide a directory to write the files to. Please note there’s a bug in the current version that prevents SQL Developer from running in an acceptable amount of time if a large amount of FLASHBACK data attached to a table. This can be avoided by either
- Running as a low privileged user – CONNECT is all that is required to documents a schema
- Removing tables from the list of objects to be documented
This bug has already been fixed and addressed for the next release.
Instead of putting in a bunch of screenshots, here’s the full HTML report to play with
Get started with a very small DB Doc HTML documentation set generated by Oracle SQL Developer v3.1.
It has a bit further to go before it’s perfect. A few bugs yes, but I’d also like to see support for generating an overview page like what you see in pldoc. I was thinking maybe a dynamic page that lists the date, connection name, and version of SQL Developer used to generate the pages. Then the end users can mod it up or replace it with whatever serves their purposes. And then maybe make this available via the command-line so you can build it into your build process.
And so we continue to ‘the next version!’



Twitter
RSS
GooglePlus
Facebook
Mar 21, 2012 @ 13:21:54
We have most of our PL/SQL code commented with PLDoc tags and we them run through PLDoc, so this feature looks very handy. One suggestion I have is to show the “Generate DB Doc…” in the pop-menu when right-clicking on any object, not just the connection. That way, you can select which objects (or whole schemas) that you want to document. An alternative might be to allow the selection of schema and objects in the pop-up window somehow. Looks like it only works for objects owned by the connected user for now, correct?
Mar 21, 2012 @ 13:38:48
Tied to connection schema, yes.
Great ideas on the per object and object/schema selection. Would you mind submitting those to the Exchange?
Jul 05, 2012 @ 13:51:33
PLDoc shows everything in the package specification. Is there a way to also get the code in the package body?
Raoul
Jul 05, 2012 @ 15:05:27
You mean private objects documented in the body and not in the spec? If they’re private, why would you want them documented
Jul 06, 2012 @ 06:48:45
I guess if you put it that way. I was looking for a way to document everything for me and my team.
Jul 06, 2012 @ 06:58:39
We could add support for the package bodies, I’m just trying to understand what information is missing by NOT including the bodies. The only thing that comes to mind is private package members.
Jul 06, 2012 @ 07:21:46
I was looking at it the wrong way. Looking for something to document every line of code, but that is not what PLDoc and other kinds of documentations of code is supposed to be. We just have to write more comments, which will be written in the PLDoc, so we can understand the purpose of the code.
But putting the private packages in (marked as private) could help with the understanding of the code, especially the flow of the code. Let’s say a package would take an amount of days and a employee number and return his monthly salary (public). But there are 3 ways to calculate his salary so 3 private packages are made. Then that amount is added to a calculated bonus (also a private package). It would help to be able to write out this flow.
Aug 14, 2012 @ 04:21:22
I’ve to agree with Raoul. I would like to use this feature to generate technical documentation of our code, not a user guide for end users. As such, it would be very useful to be able to document the whole package, in other words the body, and not just the specification. Note that PLDoc does allow this. Considering you can choose in the selection, which object types to document, I see no reason no to implement this. If you don’t want this and prefer keeping your package bodies undocumented, simply deselect that option.
Another feature I miss is the selection on object level. Sometimes, I just want to generate documentation for one specific package or object, not necessarily the whole schema. As such, it would be very useful to have the Generate DB Doc option at object level as well.
These are my two main issues with the feature as it exists now. Especially the first issue keeps me from making it our standard PL/SQL documentation generator.
Aug 14, 2012 @ 08:30:07
So you need to document your private package members? Or you’re putting your comments in the package body instead of the spec, or you’re putting them in both place?
Object level docs is an interesting idea. Can you submit that to the Exchange?
Aug 14, 2012 @ 08:50:47
Hello Jeff,
Thanks for your reply. I’ve submitted a request for both both points.
And yes, the idea would be to put comments in both the specification and body, as the goal and needs might be different. The spec doc would be more like a user guide for client developers, imagine a Java or .NET developer who wishes to call a package procedure and needs a brief explanation about what the procedure does, without having to know much about the inner workings. Whereas the body doc would be aimed at PL/SQL developers who need to make changes to the logic contained in the body or need to understand the inner workings as part of a bigger whole.
Sep 11, 2012 @ 16:03:52
Hi Jeff,
I’m glad to see that the DB Doc tool has been improving. I was really glad to see that if you have custom editor tabs defined, they get picked up by the DB Doc tool and documented (I’ve got both a References and a Referenced By tab for viewing the referential integrity constraints).
However, I noticed that any tab that has detail information opens a new browser window to the detail when you click on the row number. A nicer approach would be to include a details pane below the parent data. None of the tabs I looked at had more than one detail section but there’s no reason they couldn’t, so the child section should also contain a tab set for each of the child detail sections. I’ve added a [request|https://apex.oracle.com/pls/apex/f?p=43135:7:::::P7_ID:34681] on the exchange.
I do have one question at this time though,
What attribute tags does the DB Doc feature currently understand? Your example showed an @headcom attribute, but that appeared to be passed through without being touched wheras the @param and @returns tags were processed just fine.
I typically use the @version and @author tags in my comments and if multiple developers work on a piece of code the @author tag may appear more than once.
Apr 18, 2013 @ 06:59:05
Hi Jeff,
I am an active user of this “Generate DBDoc” feature and I have an issue with my package documentation. I have properly documented all objects in the package spec including functions, procedures and types, but I haven’t see any types description in an output HTML, only functions and procedures. Is this a known bug or I am doing something wrong?
Thank you!
Apr 18, 2013 @ 08:15:29
Smells like a bug to me, but I’ll have to reproduce locally to confirm. We’ve done a lot of work for this feature in the next release so it might already be ‘fixed.’ Will let you know!
Apr 18, 2013 @ 08:24:13
Thanks Jeff,
Sounds good! Could you, please, tell me an estimated date of the next release? If it is not a “top secret” ranked information of course
Apr 18, 2013 @ 09:05:16
It’s pretty top secret
As a rule we don’t talk about release dates.
Apr 19, 2013 @ 10:27:03
So my own example of this feature clearly demonstrates this bug – boo on me for not catching it. Talking with the developer now to see what the story is. Thanks for bringing it to my attention Anton.
Apr 20, 2013 @ 04:51:57
Jeff,
I am interested to get the comfortably working tool, so I’m glad to help you to make it better
Hope that the bugfix will be included in the next release. Thank you for a really fast reaction – your work is your passion for sure )