D
dbeavon
Guest
We still have lots of programs that compile at runtime. They use "compile-time" parameters to build programs on the fly that have varying FOR EACH logic to query the data out of the database. We have a large number of legacy programs which gather data in this way. But my understanding is that many years ago that approach went out of favor. I think the new approach is to use dynamic queries (QUERY-PREPARE) that serve a similar purpose in that they dynamically alter the logic and prepare different sets of data. (Docs: OpenEdge 11.7 Documentation ) I think the advantage here is that much more of the code can be compiled ahead of time, and there is less risk of runtime problems in the logic. Also the performance is probably a bit better when using this approach, since only a very small portion of code is evaluated on the fly. BTW, How long ago did the original approach go out of favor (ie. the dynamic compilation of source code based on runtime conditions)? In general it has not been straightforward to switch legacy "compile-time" program to the corresponding QUERY-PREPARE. Here are some things I have tried to research but haven't found an answer for: What is the limit in the size of a query-prepare statement? If I have 100 predicates for my FOR EACH, will they all fit? How about 1000? Is it a character limit? Is the QUERY-PREPARE supposed to use a local schema cache? I've discovered that a lot of the network traffic when using this approach can be related to gathering schema. I haven't found a way to optimize the schema side of things. The caching doesn't seem to work and the retrieval of schema can be slow over client/server. How do I introduce arguments to my query predicates? Do they have to be included as hard-coded literals? Can't we parameterize these queries or use locally scoped memory variables as predicates? It surprises me that I haven't yet learned of a general-purpose way to introduce arguments for my query statements. The hard-coded literal approach seems quite primitive. Are there "gotchas" that would prevent the execution plan of QUERY-PREPARE from running the same way as a similar program that is compiled statically? The reason I ask is because I noticed that the Progress product team had omitted some of the new product features/enhancements on this side of things (or at least that the features are delayed). It seems worrisome if we can't rely on this stuff working exactly the same as a corresponding statically-compiled program. I suspect there is a KB that contains the answer to some of these questions. Let me know if I'm overlooking something. Any guidance would be greatly appreciated.
Continue reading...
Continue reading...