ABL queries - Forum - OpenEdge Development - Progress Community
 Forum

ABL queries

  • There are growing discussions about the ABL queries short comings.

    There is considerable effort coming from the community to convince Progress, without much success or so it seems, calling for no index scans.

    IMO with all due respect, I think, they're fighting for scraps. What about index only scans, index skip scans etc.

    There needs to be a more fundamental change in respect to ABL queries.

    A few more things that I feel have been neglected and Progress seems to be accepting is that static and dynamic queries don't have the same fundamental capabilities.

    Specifically BREAK BY and CAN-FIND of course they have work arounds/solutions etc.

    But they still have considerable tradeoffs and not least important is their complexity and they aren't as obvious to everyone.

    I've seen alot of problematic and costly implementations of break by in dynamic queries. I also think the article in the KB could be improved on just abit.

    I am very excited about all the advancements in ABL and where its going but I think alot of us would really appreciate some return to basics.

  • There needs to be a more fundamental change in respect to ABL queries.

    I'd go farther than that - PSC needs to be more open about how it makes its decisions with respect to the language's future. From what I've seen so far, these decisions appear to be based more on which wheel's making the most noise as much as it is about technical innovation and making the language consistent across platforms (witness the ongoing lack of a dynamic ChUI browse).

    Right now - the engine can do no-index scans. The ABL, however, cannot. Why? From the engine guy I talked to, the language people don't think anyone would use it. To me the sheer utility of something like that - or for the compiler when it determines a table scan is needed to satisfy a query condition - would seem self-evident.

    A few more things that I feel have been neglected and Progress seems to be accepting is that static and dynamic queries don't have the same fundamental capabilities.

    I agree - they did a great job bringing dynamic queries to the language - but then they stopped. While it is possible to make interacting with dynamic and static queries identical, this is just one of the things the language itself should make easier to do.

    For anyone who'se interested - a copy of the query manager I wrote to make interacting with a queries easier has been submitted to the "Code Share" area, where's it's currently under review. A copy is available right now at http://amduus.com/OpenSrc/SrcLib/QueryMgr/, and I anticipate it'll be posted to the PEG Utilities page when Greg gets time.

  • I applaud you for your contribution. I think you and guys like you make a huge change and value to the community !

    I found the query manager to be a very interesting project, though for me handles and abstracting dynamic queries isn't so much of an issue

    as features like BREAK BY and CAN-FIND these short comings really complicate things, as I see it.

    I'm not saying there aren't hurdles to over come but it makes the language soo much simpler to use.

    Of course for one queries aren't forward only like for each statements, though IMVHO its solvable.

    Maybe a construct that forward scans queries is worth thinking about ?

    Another thing I'd love to see is outer joins in for each statements. Again, it would make the language much more elegant and easier to use.

    I'm sure it'll get great feed backs.

    No index scans and other types of scans solve real problems and add real value and you can find them in practically every database for years and years now.

    Talk about frustrating.

  • Of course for one queries aren't forward only like for each statements, though I IMVHO its solvable.

    That depends on your -noautoreslist setting. The default is not forward only.

    For queries associated with a browse, the default is not forward only. For other queries, there's no reliable way to tell if a query's forward-only or not with the current implementation of qh:FORWARD-ONLY.

  • I'm aware that queries can be forward-only.

    What I meant is that because queries can be scrollable maybe its not a natural fit for BREAKY BY like for each statements.

    But again, its in noway to say BREAK BY and queries can't go together.

    And the right place for them, for simplicty, certainly performance is a core feature in the language.

  • I'd go farther than that - PSC needs to be more open about how it makes

    its decisions with respect to the language's future. From what I've seen so

    far, these decisions appear to be based more on which wheel's making the

    most noise as much as it is about technical innovation and making the

    language consistent across platforms (witness the ongoing lack of a

    dynamic ChUI browse).

    Actually, I would say that the lack of a dynamic ChUI browse was a good example of them being able to ignore noise!

    Historically, it seemed to me that the biggest driver of language innovation was the tools group, i.e., if they needed something, they got it and otherwise it was very chancy. With 10.1A, though, I think we have a clear example of a market-driven and concept0-driven set of enhancements. Indeed, if anything, the irony is in how slow the group that historically might have been driving this innovation has been in actually using any of it. One might argue that ProDataSets was a precursor to this concept driven pattern, but certainly the OO stuff in 10.1A was a pretty dramatic shift.

    Regardless, wishing the process would change isn't likely to change the process. Documenting what you want, why you want it, what impact it will have, and how many people it impacts might change the process. Some proposed changes are essentially self documenting because all of the people involved agree that they should happen. Others aren't. You might be able to change that.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I'd go farther than that - PSC needs to be more open about how it makes

    its decisions with respect to the language's future. From what I've seen so

    far, these decisions appear to be based more on which wheel's making the

    most noise as much as it is about technical innovation and making the

    language consistent across platforms (witness the ongoing lack of a

    dynamic ChUI browse).

    Actually, I would say that the lack of a dynamic ChUI browse was a good example of them being able to ignore noise!

    Historically, it seemed to me that the biggest driver of language innovation was the tools group, i.e., if they needed something, they got it and otherwise it was very chancy. With 10.1A, though, I think we have a clear example of a market-driven and concept0-driven set of enhancements. Indeed, if anything, the irony is in how slow the group that historically might have been driving this innovation has been in actually using any of it. One might argue that ProDataSets was a precursor to this concept driven pattern, but certainly the OO stuff in 10.1A was a pretty dramatic shift.

    Regardless, wishing the process would change isn't likely to change the process. Documenting what you want, why you want it, what impact it will have, and how many people it impacts might change the process. Some proposed changes are essentially self documenting because all of the people involved agree that they should happen. Others aren't. You might be able to change that.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I read all the white papers you’ve published but does it work ? and like wise thats the general impression with the ERS and how useful it is.

    Maybe if things were different there would be a lot more people doing the same.

    But that's the great thing about this place and having access to the guys at Progress.

    There’s always been a huge effort when it comes to high volume transactions. That’s all you hear about when it comes to performance.

    But with queries just making them work is good enough.

    It’s not just performance queries capabilities still have holes in them.

    Like I said, no index scans, index skip scans, index only scans and many other features have real value and solve real world problems.

    Bottom line is that ABL queries have been allowed to slip further and further behind.

    And that’s what I meant when I said we’re fighting for scraps. Even if we do get no index scans we’ll still be years and years behind.

    There needs to be a more fundamental change with respect to that subject.

    And not having BREAK BY and CAN-FIND in queries and OUTER-JOINS in for each statements really complicate and lead to many problematic implementations.

  • So, some of what you want is in the engine now and all we need is a language construct to access it. To me, that is a no brainer, but it still might take someone to write it up and make the point.

    Some of it is in the SQL engine, but not in the way ABL interacts because of SQL's set orientation vs ABLs record orientation. That probably takes more work because it requires both language and changes in the plumbing. The latter could be non-trivial. But, doesn't mean that someone shouldn't write it up and make the point and see what happens.

    The alternative, of course, is to actually use SQL for some of these queries because it will have the fast scan and query optimizer. I think that might bear looking into as well.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • That'd be great ! How does one go about using OpenEdge SQL with ABL

  • Well, probably in a way that is a whole lot like one would use it in any other OO language, by creating a connection object.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I'm guessing you're suggesting it as an enhancement request to the ABL and not for us to write ?

    Maybe, things like XQuery that also combine access to the database will offer a backdoor to those type features in future releases ?

    Even though SQL is set oriented and ABL is record slash navigation oriented.

    I don't see why no index scans, other types of scans and optimizing queries in one way or another can't be done in ABL.

  • I don't see why no index scans, other types of scans and optimizing queries in one way or another can't be done in ABL.

    The usual "explanation" is "no one would use it."

  • I have, actually, suggested a connection object for ABL type connections, but I'm not actually sure that any language development is needed to provide a SQL connection object.

    I don't see why no index scans, other types of scans and optimizing

    queries in one way or another can't be done in ABL.

    To be sure, it isn't unimaginable, but it might require a bit of twisiting. E.g., suppose the magic to get some of those results was to use PRESELECT, which essentially turns the query into set oriented. Would that be acceptable?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • To be sure, it isn't unimaginable, but it might require a bit of twisiting. E.g.,

    suppose the magic to get some of those results was to use PRESELECT, which

    essentially turns the query into set oriented. Would that be acceptable?

    IMHO there's no need to take everything apart, start over or speak in those terms, not at all.

    It can even be a 4GL utility that takes in SQL like statements string and translates it into a dynamic query.

    I've worked on the subject in the past and there's so much more to say.

    I'm planning on posting a more thorough article and code to further the subject later on this year.