Bo Pedersen
Member²
I like the possibility to generate documentation from the object definitions. I have however found a couple of points that hinders/minimise the usefullness from our point of view.
[*] With global cross-reference the performance is to poor. Also when compared to javadoc, which does the same job based on Java files.
[*] Plsql is too database oriented. The only possibility to generate for several/all of the system objects is to select them in the browser and generate them from here. And then regenerate them to get cross-references. A batch interface that could generated based on a set of files would improve the usefulness greatly and also make the performance problem less of a problem
[*] The index should have navigation links for the users/schemas and objects types. As now we get a very large index file that is cumbersome to scroll in.
[*] A searchable index to answer questions like: Which package contain the set_property function? Which tables contain a status field.
[*] Strict comments can generally not be used since SQL*Plus will interpret @param inside a strict comment as a file execution command.
[/list]
If you can solve some of these problems then it will become a superb component.
[*] With global cross-reference the performance is to poor. Also when compared to javadoc, which does the same job based on Java files.
[*] Plsql is too database oriented. The only possibility to generate for several/all of the system objects is to select them in the browser and generate them from here. And then regenerate them to get cross-references. A batch interface that could generated based on a set of files would improve the usefulness greatly and also make the performance problem less of a problem
[*] The index should have navigation links for the users/schemas and objects types. As now we get a very large index file that is cumbersome to scroll in.
[*] A searchable index to answer questions like: Which package contain the set_property function? Which tables contain a status field.
[*] Strict comments can generally not be used since SQL*Plus will interpret @param inside a strict comment as a file execution command.
[/list]
If you can solve some of these problems then it will become a superb component.
