Temp-Table as a property
- Thread starter DevTeam
- Start date
Thanks for your answer.
We currently have some 4GL code that declares a temp-table as a shared variable, which is more efficient than passing temp-table as output parameters...
In ABL, as it is impossible to declare shared variables in .cls files, I figured that declaring it as a public property was the - quite ugly - equivalent... Bad luck !
What do you think of declaring a getter method that returns the temp-table's buffer handle in order to manipulate it from outside the class (even if dynamic queries are less efficient than static ones) ?
We currently have some 4GL code that declares a temp-table as a shared variable, which is more efficient than passing temp-table as output parameters...
In ABL, as it is impossible to declare shared variables in .cls files, I figured that declaring it as a public property was the - quite ugly - equivalent... Bad luck !
What do you think of declaring a getter method that returns the temp-table's buffer handle in order to manipulate it from outside the class (even if dynamic queries are less efficient than static ones) ?
TomBascom
Curmudgeon
1) I'd have to wonder why you're bothering to use an OO concept like a class if you're going to so brazenly disregard the conceptual basis of OO.
2) I disagree with the assertion that a dynamic query is less efficient than a static query.
3) There are multiple ways to pass TTs around. There are many trade-offs.
2) I disagree with the assertion that a dynamic query is less efficient than a static query.
3) There are multiple ways to pass TTs around. There are many trade-offs.
1) I initially wanted to access the Temp-Table member through a getter method. Be my guest, show me how to do this another way than returning a buffer handle or via an output parameter. I mean a true METHOD PUBLIC with a RETURN statement (when I try the "METHOD PUBLIC Temp-Table getTT(), the compiler seems to try and find the Temp-Table.cls file... ).
2) That's true that I did not benchmark this, but how could dynamic be better with its whole runtime parsing ?
3) I'm not sure I understand correctly the "trade-off" expression (I apologize for my English)
tamhas
ProgressTalk.com Sponsor
I do recommend looking up the thread on the PEG since I think it would provide you with many ideas and the arguments about why some of them are bad ideas. Your statement that one can't use temp-tables in .cls files is not correct, though perhaps you meant that you couldn't make it a shared temp-table.
The core principle here is that a class is supposed to encapsulate its implementation so that, from the outside, one can't tell whether it is using a temp-table, database table, work-table, linked list, bunch of variables or whatever. Put all the logic of manipulating the temp-table inside the class and expose methods which relate to behavior, not implementation.
The core principle here is that a class is supposed to encapsulate its implementation so that, from the outside, one can't tell whether it is using a temp-table, database table, work-table, linked list, bunch of variables or whatever. Put all the logic of manipulating the temp-table inside the class and expose methods which relate to behavior, not implementation.
TomBascom
Curmudgeon
The only real difference between a dynamic query and a static one is the "query-prepare" step. This is, essentially, a compile at runtime. Unless the query is a single record fetch it is probably not a significant component of query performance. And if it is just a single record then the total runtime isn't enough to bother over.
Other than that a dynamic query is just like a pre-compiled static query.
As for how to do it the "proper" OO way, Thomas is a better source of info than me. I'm an unrepentant OO scoffer who brazenly advocates all sorts of heresies :awink:
Other than that a dynamic query is just like a pre-compiled static query.
As for how to do it the "proper" OO way, Thomas is a better source of info than me. I'm an unrepentant OO scoffer who brazenly advocates all sorts of heresies :awink:
Your explanation is right, if you limit the comparison to the query only.
But, if I remember well, underneath a dynamic query is a buffer, which is also dynamic. And each access to a field of this buffer is done through "BUFFER-FIELD(fldName)", isn't it ?
I was not judging at all ! My bad if you got this feeling... As Thomas said, maybe the idea of accessing an internal TT is wrong, or maybe is this TT stuff not fitted to this OO environment (maybe PDS suit better). As I was advised, I will look up PEG forums about ABL best practices.
Thanks again to both of you for those good pieces of advice.
Julien
TomBascom
Curmudgeon
Accessing elements of a dynamic query can be done in many ways.
The method that you mention, involving handles, is perhaps "ugly" from a certain POV but it isn't a performance problem of any special note. Rather than preclude their use out of hand you might be pleasantly surprised if you gave them a try. They are very useful constructs when their use is appropriate.
The method that you mention, involving handles, is perhaps "ugly" from a certain POV but it isn't a performance problem of any special note. Rather than preclude their use out of hand you might be pleasantly surprised if you gave them a try. They are very useful constructs when their use is appropriate.
tamhas
ProgressTalk.com Sponsor
There is nothing inherently wrong about TT and OO and nothing about PDS that are more well suited. A PDS is really a sort of pseudo-object with a fixed set of overridable methods. Both TTs and PDSs are 4GLish things not found in most 3GL OO languages (unless you count datasets in .NET) so there may not be good models to relate to, but they are part of what makes ABL what it is.
The PEG discussion is good for your immediate question because it was also triggered by someone wanting to use a TT in an object and yet to pass it around and access it directly.
I will note that there is some diversity of opinion on best practice in this regard. PSC whitepapers on PSDN tend to advocate a model in which the data object is a TT or PDS which is separate from the data source object and the business logic object, where the latter is logic without data or state other when being actively used. I advocate a more standard OO approach in which data and logic are encapsulated in a single business entity object. You can read more about this here http://www.oehive.org/OERAStrategies
The PEG discussion is good for your immediate question because it was also triggered by someone wanting to use a TT in an object and yet to pass it around and access it directly.
I will note that there is some diversity of opinion on best practice in this regard. PSC whitepapers on PSDN tend to advocate a model in which the data object is a TT or PDS which is separate from the data source object and the business logic object, where the latter is logic without data or state other when being actively used. I advocate a more standard OO approach in which data and logic are encapsulated in a single business entity object. You can read more about this here http://www.oehive.org/OERAStrategies
Hi Thomas,
I have searched the thread you mentioned on PEG forums but I can't find it. Could you please send me the URL ?
Thanks in advance.
tamhas
ProgressTalk.com Sponsor
Try this one
http://www.peg.com/lists/peg/history/200709/msg00458.html
You might also want to check out http://www.psdn.com/library/thread.jspa?threadID=9532&tstart=0 ... at least if John continues the thread.
http://www.peg.com/lists/peg/history/200709/msg00458.html
You might also want to check out http://www.psdn.com/library/thread.jspa?threadID=9532&tstart=0 ... at least if John continues the thread.
Similar threads
- Locked
- Jessica Malakian
- Progress Blog
