I have two parameters, limit and page. If page is passed, limit is required. Otherwise, limit is optional. Below is my current JSDoc. How can I modify it (if this is possible) to properly show the relationship between the two?
/**
* ...
* #param {Number} [ctx.request.body.limit] A limit on the number of items to return
* #param {Number} [ctx.request.body.page] The page we are currently on. A `limit` must also be
* given when using this parameter
*/
Related
is there a way to access the query string from within a stored procedure?
i mean i'd like to add some debugging to a lot of stored procedures and it would be brilliant if i had some constant accessible from the body of the procedure, which had the query string.
something which would work with EXECUTE.
i've read the docs and cannot see anything like that...
thanks!
I agree with Pavel that your requirement is not real clear. However, I guess that you want the to get the statement that called the procedure currently running. If so then there may be a built in function: Current_Query(). Following is an example of its use.
create or replace function what_called_me()
returns text
language sql
as $$
select current_query();
$$;
select 1 num, 'A' col, what_called_me() sql_statement;
I don't understand well, what you need, but maybe you need plpgsql plugin API. This API is not well documented, but there is lot of PostgreSQL extensions that use this API - PLdebugger, plpgsql_chec, plprofiler and maybe other.
/*
* A PLpgSQL_plugin structure represents an instrumentation plugin.
* To instrument PL/pgSQL, a plugin library must access the rendezvous
* variable "PLpgSQL_plugin" and set it to point to a PLpgSQL_plugin struct.
* Typically the struct could just be static data in the plugin library.
* We expect that a plugin would do this at library load time (_PG_init()).
* It must also be careful to set the rendezvous variable back to NULL
* if it is unloaded (_PG_fini()).
*
* This structure is basically a collection of function pointers --- at
* various interesting points in pl_exec.c, we call these functions
* (if the pointers are non-NULL) to give the plugin a chance to watch
* what we are doing.
*
* func_setup is called when we start a function, before we've initialized
* the local variables defined by the function.
*
* func_beg is called when we start a function, after we've initialized
* the local variables.
*
* func_end is called at the end of a function.
*
* stmt_beg and stmt_end are called before and after (respectively) each
* statement.
*
* Also, immediately before any call to func_setup, PL/pgSQL fills in the
* error_callback and assign_expr fields with pointers to its own
* plpgsql_exec_error_callback and exec_assign_expr functions. This is
* a somewhat ad-hoc expedient to simplify life for debugger plugins.
*/
typedef struct PLpgSQL_plugin
{
/* Function pointers set up by the plugin */
void (*func_setup) (PLpgSQL_execstate *estate, PLpgSQL_function *func);
void (*func_beg) (PLpgSQL_execstate *estate, PLpgSQL_function *func);
void (*func_end) (PLpgSQL_execstate *estate, PLpgSQL_function *func);
void (*stmt_beg) (PLpgSQL_execstate *estate, PLpgSQL_stmt *stmt);
void (*stmt_end) (PLpgSQL_execstate *estate, PLpgSQL_stmt *stmt);
/* Function pointers set by PL/pgSQL itself */
void (*error_callback) (void *arg);
void (*assign_expr) (PLpgSQL_execstate *estate, PLpgSQL_datum *target,
PLpgSQL_expr *expr);
} PLpgSQL_plugin;
This is necessary when you really need to detail info about what is inside.
Maybe you need information just about executed queries - then you can look on extension auto_explain, when you set auto_explain.log_nested_statements to on, then the queries from procedure will be logged.
In all my APIs I have a line of text that gets repeated. Is there a way to put that text in one place and link to it from the APIs?
For instance, in the below example, how to put the 'text that is common for many APIs' in one place, instead of writing the same thing in all the APIs?
/**
* #brief Function description
* #param [in] param function param description
* #return return description
*
* #attention text that is common for many APIs
***********************************************************************/
int func(int param);
In case it is always the same line, best would be to define a special command for it by means of and alias in the doxygen configuration file (Doxyfile), see the tag ALIASES
For longer texts the doxygen command \includedoc would be the way to go.
I'm sorry if it sounds too simple a question but still ...
I am documenting php code and whereas all functions etc. look good in the generated documentation,
I have problems with variable types which should be visible in the generated documentation.
I document them in this way:
/**
* $request - request object
*
* #type int
* #access private
*/
private $request;
As a result, I can see 'int' in the generated documentation, but #type is not a correct command. The proper command would be #var instead of #type but then I cannot see the type of the variable in the documentation.
So the question is "How to document a variable so I can see its type?"
Please help :)
I'm writing a User Macro in Confluence 5 and I found that the 10th parameter is not being interpreted.
This is my macro header:
## #param ArtifactVersion:title=Artifact Version|type=string|required=true
## #param Contacts:title=Contacts|type=string|required=true
## #param Date:title=Date|type=date|required=true
## #param RollbackVersion:title=Rollback Version|type=string|required=true
## #param QaEngineer:title=QA Engineer|type=string|required=false
## #param ArtifactId:title=Artifact Id|type=string|required=true
## #param SiteName:title=Site Name|type=string|required=true
## #param Servers:title=Servers|type=string|required=true
## #param Instance:title=Instance|type=enum|enumValues=0,1,2,3,4,5,6,7,8,9,10|required=true
## #param MyParam:title=My Param|type=string|required=true
If I add another param (MyParam) then it is not being interpreted. It just prints $paramMyParam literally.
I'm fairly certain that there is an underlying limitation of 9 params in Confluence user macros. Whether or not this is a deliberate design decision, a limitation of the underlying architecture, or simply an oversight/bug, I cannot say.
If this is a deal-breaker for your macro, you could consider re-writing it as a fully-fledged Macro module using a Java plugin.
I am not certain you can have the 10th parameter, but I believe you could combine 2 parameters into 1 to allow room for the last one.
Artifact version and Artifact ID sound like they could be parsed out of the same string, similar to the way you would do so for the list of servers you have for your 8th parameter.
I'm trying to write documentation in Texinfo format (must be traditional to Emacs, I guess). And it is a nightmare... Anyway, I could get to the point, where the source gives me less error then when I started, but the errors are impossible to understand and thus fix.
All of the errors boil down to "bad" next / previous / up nodes. And they all happen in places, where there can be no "next", no "previous" and no "up" nodes. I.e. The last node in the list does not have a next node, similarly, the first can't have a previous, and the top-level can't have an "up". Node. These are the exact messages I'm getting:
./i-iterate/info/i-iterate.texi:385: Next field of node
`dot-product|join|distinct' not pointed to (perhaps incorrect
sectioning?).
./i-iterate/info/i-iterate.texi:392: This node (return)
has the bad Prev.
./i-iterate/info/i-iterate.texi:199: Next field of
node `initially' not pointed to (perhaps incorrect sectioning?).
./i-iterate/info/i-iterate.texi:120: This node (for) has the bad Prev.
./i-iterate/info/i-iterate.texi:29: Next field of node `Top' not
pointed to (perhaps incorrect sectioning?).
./i-iterate/info/i-iterate.texi:120: This node (for) has the bad Prev.
My texti file structure is as follows:
- Top
|- menu-0
| |- menu-2
|- menu-1
<list of nodes>
I.e. nodes mentioned in menu-2 should have their top node in menu-0, and Top is the top node for nodes in menu-0 and menu-1.
for node is the first node in the menu-0, return node is the first node in the menu-1, dot-product|join|distinct is the last node in menu-2, initially is the last node of the menu-0.
Top node can't have previous / next / up nodes... for obvious reasons.
As requested, the offending nodes:
#node for, with, , Top
#node return, collect, , Top
#node dot-product|join|distinct, , permutations, for
#node initially, , finally, Top
Some more info. I could actually "fix" it by specifying the return node as the next node of initially and initially as a previous node of return. But this is not the desired effect, because they two belong in different sets of nodes.
Also, this is how the entire menu looks like:
#menu
* for:: A multi-purpose driver for doing variety of things.
* with:: A driver for variable declaration.
* generate:: A general purpose generator driver.
* repeat:: A simple driver for performing iteration N number of itmes.
* finally:: A driver that runs when the iteration finishes normally.
* initially:: A driver that runs before any code in the iteration.
#end menu
#strong{Keywords}
#menu
* return:: Returns the control flow to the form outside the loop.
* collect:: Generates a list with the cells being the experssion given.
* hash:: Generates a hash-table with the provided keys and values.
* skip:: Skips the execution of the rest of the loop body.
* previous:: Gives the value of the variable from the previous iteration.
* next:: Gives the value of the variable from the next iteration.
* output:: Prints the variable to the dedicated stream.
* insert:: Generates a vector and inserts elements into it.
* minimize:: Finds the minimum value of the variable.
* maximize:: Finds the maximum value of the variable.
* count:: Counts the number ot times this expression was executed.
* sum:: Sums the values of this variable.
* multiply:: Multiplies the values of this variable.
* reduce:: General purpose accumulation handler.
#end menu
#node for, with, , Top
#chapter Multi-purpose driver
... description of what for node is ...
#strong{For continuations}
#menu
* in|on:: Iterates over lists.
* upfrom|from|downfrom:: Iterates numberically.
* across|reverse|binary:: Iterates over arrays.
* depth-first|breadth-first:: Iterates over trees.
* keys|values|pairs:: Iterates over hash-tables.
* random:: Produces unique random each iteration.
* chars|words|lines:: Iterates over entities in buffer.
* permutations:: Generates permutation of an array.
* dot-product|join|distinct:: Iterates over sets.
#end menu
Just use #node for and #node return without the extra arguments. Texinfo will then automatically figure out the prev/next/up links based on #chapter and other sectioning commands.