I'm trying to overwrite the parameter handler, so it'd point to another temp-table with different schema.
myProcedure.p
DEFINE TEMP-TABLE TT_RealTable NO-UNDO
BEFORE-TABLE TT_RealTableBefore
FIELD name AS CHAR
.
DEF INPUT-OUTPUT PARAM TABLE-HANDLE TH_NewTable.
CREATE TT_RealTable.
ASSIGN TT_RealTable.name = "Ben".
CREATE TT_RealTable.
ASSIGN TT_RealTable.name = "Harry".
The TH_NewTable points to a random parameter TEMP-TABLE with different schema and contents. I want to overwrite this parameter TABLE-HANDLER with the TT_RealTable. If I try to set:
TH_NewTable = TEMP-TABLE TT_RealTable:HANDLE.
The program will crash at runtime saying that TT_RealTable's schema/meta data doesn't match the handler's one.
How I can overwrite the handler to point to my TT_RealTable:HANDLE, and return it as output?
If the schema IS different as the error claims, and you said at the beginning of your post, what you want to do can't be done. You can't pass a temp-table buffer handle that has a certain definition and return something else at the end of the procedure, assuming the parameter table handle is from a static temp-table. Even if it isn't, you'd need to create the temp-table using the buffer handle AFTER calling the procedure, which I'm thinking is not what you want, since your parameter is input-output.
If you really want to work with a table that's fluid as far as schema goes, you should read into dynamic temp-tables. Look for the CREATE TEMP-TABLE statement in help and read through the examples to understand how you can get a handle and then (and only then) build a temp-table using the returned handle, so you can use that. You lose the ability of using regular statements, though, such as create and assign. You'll have to reference BUFFER-FIELD and BUFFER-VALUE, and use the CREATE method instead, using the buffer-handle. Might take a while to get used to it, but it's not rocket science.
Hope it helps!
Related
I was looking inside the create_vlabel function and noted that to get the graph_name and label_name it is used graph_name = PG_GETARG_NAME(0) and label_name = PG_GETARG_NAME(1). Since these two variables are also passed as parameters, I was thinking that, if I wanted to add one more parameter to this function, then I would need to use PG_GETARG_NAME(2) to get this parameter and use it in the function's logic. Is my assumption correct or do I need to do more tweaks to do this?
You are correct, but you also need to change the function signature in the "age--1.2.0.sql" file, updating the arguments:
CREATE FUNCTION ag_catalog.create_vlabel(graph_name name, label_name name, type new_argument)
RETURNS void
LANGUAGE c
AS 'MODULE_PATHNAME';
Note that all arguments come as a "Datum" struct, and PG_GETARG_NAME automatically converts it to a "Name" struct. If you need an argument as int32, for example, you should use PG_GETARG_INT32(index_of_the_argument), for strings, PG_GETARG_CSTRING(n), and so on.
Yes, your assumption is correct. If you want to add an additional parameter to the create_vlabel function in PostgreSQL, you can retrieve the value of the third argument using PG_GETARG_NAME(2). Keep in mind that you may need to make additional modifications to the function's logic to handle the new parameter correctly.
The answers given by Fahad Zaheer and Marco Souza are correct, but you can also create a Variadic function, with which you could have n number of arguments but one drawback is that you would have to check the type yourself. You can find more information here. You can also check many Apache Age functions made this way e.g agtype_to_int2.
By default, when IPython displays an object, it seems to use __repr__.
__repr__ is supposed to produce a unique string which could be used to reconstruct an object, given the right environment.
This is distinct from __str__, which supposed to produce human-readable output.
Now suppose we've written a particular class and we'd like IPython to produce human readable output by default (i.e. without explicitly calling print or __str__).
We don't want to fudge it by making our class's __repr__ do __str__'s job.
That would be breaking the rules.
Is there a way to tell IPython to invoke __str__ by default for a particular class?
This is certainly possible; you just need implement the instance method _repr_pretty_(self). This is described in the documentation for IPython.lib.pretty. Its implementation could look something like this:
class MyObject:
def _repr_pretty_(self, p, cycle):
p.text(str(self) if not cycle else '...')
The p parameter is an instance of IPython.lib.pretty.PrettyPrinter, whose methods you should use to output the text representation of the object you're formatting. Usually you will use p.text(text) which just adds the given text verbatim to the formatted representation, but you can do things like starting and ending groups if your class represents a collection.
The cycle parameter is a boolean that indicates whether a reference cycle is detected - that is, whether you're trying to format the object twice in the same call stack (which leads to an infinite loop). It may or may not be necessary to consider it depending on what kind of object you're using, but it doesn't hurt.
As a bonus, if you want to do this for a class whose code you don't have access to (or, more accurately, don't want to) modify, or if you just want to make a temporary change for testing, you can use the IPython display formatter's for_type method, as shown in this example of customizing int display. In your case, you would use
get_ipython().display_formatter.formatters['text/plain'].for_type(
MyObject,
lambda obj, p, cycle: p.text(str(obj) if not cycle else '...')
)
with MyObject of course representing the type you want to customize the printing of. Note that the lambda function carries the same signature as _repr_pretty_, and works the same way.
We're migrating to 11.6 and I think it's a great moment to rethink old habits and improve some concepts.
One of these things is the way we've been dealing with parameter definitions in functions and procedures.
Often times we have procedures and functions that need a lot of parameters, either inputs or outputs. Personally, for readability and maintainability reasons, I don't like to have methods with too many parameters explicitly declared.
In order to avoid this problem and still allow a large number of parameters, we've manually implemented a key-value pair approach with a single parameter.
But there are some drawbacks with this approach:
It's not possible to tell which parameters are needed just by inspecting
the method signature.
You'll always need some boilerplate code, like methods for pushing and pulling values.
So with that said, I would like to hear some others' thoughts.
Have you ever implemented something similar?
Is there something that could work as a javascript/json object in ABL?
Current implementation.
DEFINE VARIABLE param as CHARACTER NO-UNDO.
addValue('id', '1', param).
addValue('date', STRING(TODAY), param).
RUN internalProc (INPUT param).
Desired implementation
param.id = 1
param.date = TODAY
RUN internalProc (INPUT param)
Since you are mentioning 11.6, why not use a real class based object (available since 10.1A).
yourpackage\yourparameter.cls:
CLASS yourpackage.yourclass:
DEFINE PUBLIC PROPERTY date AS DATE NO-UNDO
GET.
SET.
DEFINE PUBLIC PROPERTY id AS INTEGER NO-UNDO
GET.
SET.
CONSTRUCTOR PUBLIC yourclass ():
SUPER ().
END CONSTRUCTOR.
CONSTRUCTOR PUBLIC yourclass (pid AS INTEGER, pdate AS DATE):
SUPER ().
ASSIGN THIS-OBJECT:id = pid
THIS-OBJECT:date = DATE .
END CONSTRUCTOR.
END CLASS.
and the internal procedure:
DEFINE INPUT PARAMETER poParameter AS yourpackage.yourclass NO-UNDO .
and the caller:
DEFINE VARIABLE o AS yourpackage.yourclass NO-UNDO.
o = NEW yourpackage.yourclass().
o:id = 42.
o:date = TODAY.
RUN internalProc (o) .
alternative caller:
RUN internalProc (NEW yourpackage.yourclass (1, TODAY)) .
The ABL provides full OO capabilities from 10.1A on and that can be mixed nicely with procedural code. And parameter objects (structs) is a great way to get started with a few inital classes in legacy code.
If you define a DSL file with some lines, and one of them uses a variable, you cannot use it twice in a rule because you will get a duplicate variable error.
What's the best way to avoid this? Ideally I would like to avoid to create two copies of the DSL line to just change the variable name.
ie, the DSL line:
[when][]For all qualifications of type Higher=$highers: Higher()
this cannot be used twice in the same rule or we get a duplicate $highers variable.
You can synthesize the name of a binding variable like any other chunk of text:
[when][]there is a qualification of type {qualification}=
${qualification}: {qualification}()
But it's going to be tricky because you'll have to make references to this variable variable variable, too:
[then] print {qualification}=System.out.println( ${qualification} );
instead of the straightforward
[then] print qualification=System.out.println( $qualification );
A lurking danger is that the amount of text that remains as a "landmark" around the macro variables is reduced which may result in multiple matches.
CREATE QUERY ohQuery.
ohQuery:SET-BUFFERS(hBuffer).
OhQuery:QUERY-PREPARE("FOR EACH " + ip-tablename ).
ohQuery:QUERY-OPEN().
ohQuery:GET-FIRST().
ip-tablename = value from UI (combo box)
Now I need to create a temp-table for this query. How to create?
If I am using create-like method what value should I pass in this?
To create a temp-table dynamically at runtime, you need either a handle to a buffer of said table, or the table-name itself. Seeing as you already have the handle to the buffer of 'ip-tablename' (I am assuming hBuffer is a buffer to the table with name 'ip-tablename', otherwise your above statement won't work), you should use that handle instead of 'just' the table-name out of performance reasons. Here's how to do it:
DEF VAR ttH AS HANDLE NO-UNDO.
ttH:CREATE-LIKE(hBuffer).
Optionally, you can also use 'ip-tablename' for the create-like method, although it doesn't perform as well:
ttH:CREATE-LIKE(ip-tablename).
Don't forget that you'll need to use the temp-table prepare method before you can use your new temp-table:
ttH:TEMP-TABLE-PREPARE("myNewTempTable").
Hope that helps!