| Author |
Message
|
| goffinf |
 Posted: Fri May 03, 2013 5:19 am Post subject: DECLARE ROW at schema scope ? |
 |
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
version: 6.1.0.10
I want to use a variable of type ROW at the schema level. Like this :-
| Code: |
BROKER SCHEMA mySchema
DECLARE LoggingProperties ROW;
|
Unfortunately that causes the compile time error :-
| Quote: |
Statements are not allowed in schema scope
|
I also tried initializing the ROW like this :-
| Code: |
BROKER SCHEMA mySchema
DECLARE LoggingProperties ROW ROW('false' AS status, 'true' AS propagate);
|
But same result.
Is this (or something equivalent) possible ?
Note: If I were to declare the variable as SHARED, both of the above would work, but I don't want that.
Regards
Fraser. |
|
| Back to top |
|
 |
| mgk |
| Posted: Fri May 03, 2013 8:25 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Sounds like a defect to me...
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 03, 2013 9:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The other thing to keep in mind, aside from the fact that you should be able to declare variables at schema scope...
Is that variables declared at schema scope are not visible outside the schema.
So whilst one can happily declare a procedure or function at schema scope, and address it by <schemaName>.<methodName>, one can not so address variables (shared, external, or otherwise). |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri May 03, 2013 10:46 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| mgk wrote: |
| Sounds like a defect to me... |
Since v6.1 is so close to EOL I guess it's unlikely that it going to be fixed... annoying though. I had developed a set of library functions which were predicated on this working. I did some initial tests but they all used a ROW variable at module scope and all worked OK. My fault for not being thorough.
I will raise a PMR a see what happens.
I also noted that even scalar variables reported the same error when declared at schema scope eg.
| Code: |
BROKER SCHEMA mySchema
DECLARE myBoolean BOOLEAN FALSE;
|
I do have a workaround using the global Environment it's just not so elegant.
I'll give it a try in v8.0.0.2 and see if it's any different. |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri May 24, 2013 5:03 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
So to round this one out, I have just had confirmation back from IBM on this issue (raised under PMR 80637,999,866)
| Quote: |
... the broker level3 team have confirmed that ROW variables are not supported at the schema level and that using the global environment
is the way to achieve your aim.
|
So it anyone was wondering that's what they said.
As for v8, the behaviour is mostly the same, that is, the problem is still present albeit there is no compile time error, but instead, an error occurs when that variable is used in ESQL.
If the variable is declared as SHARED or EXTERNAL then everything works, but of course you are then bound by the restrictions of those types.
HTHs
Fraser. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri May 24, 2013 5:09 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| goffinf wrote: |
So to round this one out, I have just had confirmation back from IBM on this issue (raised under PMR 80637,999,866)
| Quote: |
... the broker level3 team have confirmed that ROW variables are not supported at the schema level and that using the global environment
is the way to achieve your aim.
|
So it anyone was wondering that's what they said.
As for v8, the behaviour is mostly the same, that is, the problem is still present albeit there is no compile time error, but instead, an error occurs when that variable is used in ESQL.
If the variable is declared as SHARED or EXTERNAL then everything works, but of course you are then bound by the restrictions of those types.
HTHs
Fraser. |
Sounds like a job for SINGLETON-man.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri May 24, 2013 5:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| goffinf wrote: |
If the variable is declared as SHARED or EXTERNAL then everything works, but of course you are then bound by the restrictions of those types.
HTHs
Fraser. |
Sounds like a job for SINGLETON-man. |
A SHARED variable is a Singleton, man. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri May 24, 2013 6:45 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| A SHARED variable is a Singleton, man. |
"Sure Kaffe, Lt. Kendrick will take you by Personnel on your way back to the flight line and you can have all the transfer orders you want." -- Col Jessup AFGM
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Esa |
| Posted: Fri May 24, 2013 7:33 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| goffinf wrote: |
So to round this one out, I have just had confirmation back from IBM on this issue (raised under PMR 80637,999,866)
| Quote: |
... the broker level3 team have confirmed that ROW variables are not supported at the schema level and that using the global environment
is the way to achieve your aim.
|
So it anyone was wondering that's what they said.
As for v8, the behaviour is mostly the same, that is, the problem is still present albeit there is no compile time error, but instead, an error occurs when that variable is used in ESQL.
If the variable is declared as SHARED or EXTERNAL then everything works, but of course you are then bound by the restrictions of those types.
|
Yes, the only reason why you would create a ROW variable or any other type of variable on schema scope is that you want to share information between ESQL nodes within a flow instance.
In other words: you want to create your own Environment tree.
Because that's what Environment essentially is: a ROW variable declared on default schema scope. You don't really need to declare another one, do you? |
|
| Back to top |
|
|
| goffinf |
| Posted: Fri May 24, 2013 11:26 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| Esa wrote: |
| goffinf wrote: |
So to round this one out, I have just had confirmation back from IBM on this issue (raised under PMR 80637,999,866)
| Quote: |
... the broker level3 team have confirmed that ROW variables are not supported at the schema level and that using the global environment
is the way to achieve your aim.
|
So it anyone was wondering that's what they said.
As for v8, the behaviour is mostly the same, that is, the problem is still present albeit there is no compile time error, but instead, an error occurs when that variable is used in ESQL.
If the variable is declared as SHARED or EXTERNAL then everything works, but of course you are then bound by the restrictions of those types.
|
Yes, the only reason why you would create a ROW variable or any other type of variable on schema scope is that you want to share information between ESQL nodes within a flow instance.
In other words: you want to create your own Environment tree.
Because that's what Environment essentially is: a ROW variable declared on default schema scope. You don't really need to declare another one, do you? |
No, and that is what I did, it just that using a variable specifically declared for the purpose just seemed more elegant to me.
Since this was also part of a set of library functions as opposed to specific to a single flow, I don't like Dev's needing to know and then hard-code specific locations for things like this. So I added a separate function that encapsulates that location and makes it transparent to the caller (and hence more flexible if I want to restructure and/or relocate it later).
The functionality ends up being the same, it just a bit more plumbing for the abstraction.
Anyway, it's always good to share IBM provided info when it turns up. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Fri May 24, 2013 12:12 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
It is really really a "pattern" on broker functions (procedures) to hand in the Environment as an (the first) argument. You even name it "rEnv"... a consultant showed me... I took it ... I never tried anything else. Works ok... isnt the nicest thing on earth... but fits the purpose... wont create ((too) big) trouble down the road.
On the upside: Everything is in the "Environment".
Couldn't IBM answer "that's ... somewhat ... intentional" !? 
@esa: Very nice explanations.
@fraser: Welcome to ESQL  . (its the right choice, the quirks turn out to be advantages )
| Code: |
| DECLARE LoggingProperties ROW ROW('false' AS status, 'true' AS propagate); |
Declare a ROW: ok... Treat/fill it like a row: seems strange to me
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat May 25, 2013 9:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Based on some preliminary testing for WMBv8001:- Message flows compiled in-line don't seem to support normal schema level variables at all; the declarations literally disappear in the resulting cmf. (Though this behavior may be specific to v8001.)
- Normal schema-level variables only have a lifetime of one message passing through a node. Their values do not persist from node to node. This would limit the usefulness of any rows declared at the schema level.
- Row variables can't be passed into, or passed out of, or returned by procedure/functions, which would further limit their usefulness.
Some of this behavior is clearly documented in the InfoCenter; some of it isn't.
| goffinf wrote: |
So to round this one out, I have just had confirmation back from IBM on this issue (raised under PMR 80637,999,866)
| Quote: |
... the broker level3 team have confirmed that ROW variables are not supported at the schema level and that using the global environment
is the way to achieve your aim. |
|
Except that the "Environment" correlation identifier is not available to schema-level procedures/functions. A module-level procedure/function must pass the "Environment" reference as an argument when calling a schema-level procedure/function. Unfortunately, this type of inter-dependency between caller and called procedure/function is not always desirable. |
|
| Back to top |
|
|
| goffinf |
| Posted: Sat May 25, 2013 3:24 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| Quote: |
Message flows compiled in-line don't seem to support normal schema level variables at all; the declarations literally disappear in the resulting cmf. (Though this behavior may be specific to v8001.)
|
Same in v6.1
| Quote: |
Normal schema-level variables only have a lifetime of one message passing through a node. Their values do not persist from node to node. This would limit the usefulness of any rows declared at the schema level.
|
Not if that's the desired life-time (which it is for me in some cases). The ROW construct is a useful way of capturing related data structure at the point a message is received and making it visible to all nodes in that flow for the life-time of that thread.
| Quote: |
Row variables can't be passed into, or passed out of, or returned by procedure/functions, which would further limit their usefulness.
|
They can be passed as REFERENCE in and out quite successfully.
| Quote: |
... this type of inter-dependency between caller and called procedure/function is not always desirable.
|
Indeed. Hence my point about abstracting away at least part of that coupling. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue May 28, 2013 1:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| goffinf wrote: |
| rekarm01 wrote: |
| Normal schema-level variables only have a lifetime of one message passing through a node. Their values do not persist from node to node. This would limit the usefulness of any rows declared at the schema level. |
Not if that's the desired life-time (which it is for me in some cases). The ROW construct is a useful way of capturing related data structure at the point a message is received and making it visible to all nodes in that flow for the life-time of that thread. |
Which is the desired lifetime, one node within a thread, or the entire thread? Normal schema-level variables do not persist long enough to be visible to any other nodes. This makes them less useful for storing ROWs.
| goffinf wrote: |
| rekarm01 wrote: |
| Row variables can't be passed into, or passed out of, or returned by procedure/functions, which would further limit their usefulness. |
They can be passed as REFERENCE in and out quite successfully. |
If it were possible to declare and populate a normal schema-level ROW variable, and pass it out by REFERENCE, the node would still need to copy the ROW to a more persistent location, in order for other nodes to see it. Or else the broker would need to extend the lifetime of normal schema-level variables.
[Edit: Added "normal"]
[Edit: Or maybe that should be "do not stay in scope long enough". Persistence (lifetime) is harder to narrow down, but either way, their values aren't visible in other nodes.]
Last edited by rekarm01 on Sun Jun 09, 2013 10:58 am; edited 2 times in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 28, 2013 4:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| Which is the desired lifetime, one node within a thread, or the entire thread? Schema-level variables do not persist long enough to be visible to any other nodes. |
Really?
From experiment, or from documentation? |
|
| Back to top |
|
|
|
|
