This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 534860 - (RHQ-1615) View results for Postgres invoke sql operation doesn't show results properly
View results for Postgres invoke sql operation doesn't show results properly
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
1.1.2
All All
low Severity medium (vote)
: ---
: RHQ 4.12
Assigned To: Thomas Segismont
Mike Foley
http://jira.rhq-project.org/browse/RH...
: Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-20 06:38 EST by Joao Paulo Viragine
Modified: 2014-12-15 06:36 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
JON 2.1.2.SP1
Last Closed: 2014-12-15 06:36:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Screenshot-JON - View Operations History Details for Resource 'rhq Database' - Mozilla Firefox.png (76.25 KB, image/png)
2009-02-20 12:05 EST, Joao Paulo Viragine
no flags Details

  None (edit)
Description Joao Paulo Viragine 2009-02-20 06:38:00 EST
The results of  Postgres invoke sql operation are not formated properly. It appears
only in contents field and isn't formated as a table.
Comment 1 Heiko W. Rupp 2009-02-20 07:28:45 EST
Can you supply an example on what is bad and how it should look like?
Comment 2 Joao Paulo Viragine 2009-02-20 12:05:14 EST
I think that results should be exposed as a tabular results (like we have in view queries of Hibernate Statistics).
Currently the results are exposed in one field (I think that's is a render bug and not the intend)
See the screenshot for further details.
Comment 3 John Mazzitelli 2009-02-20 12:10:47 EST
this should be an enhancement request. This isn't a bug per-se - the data is there, just not in a format the reporter would like.

I think this operation could be enhanced by providing a new, required, parameter - "max rows" (because otherwise, a select * could concievably blow up the rhq_config_props table with milliions of rows fo data). We could then make the results a list of maps (where each map consists of a row of data - each key in the map representing a column).
Comment 4 Joao Paulo Viragine 2009-02-20 12:36:35 EST
Perfectly, I agree with you.
I was thinking that's a render bug because the results are formated as a html table, but don't showed as a html table.
Now, I now that's an intend.
Comment 5 Red Hat Bugzilla 2009-11-10 15:36:47 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1615
Imported an attachment (id=368590)
Comment 6 Thomas Segismont 2014-04-04 04:32:36 EDT
(In reply to John Mazzitelli from comment #3)
> I think this operation could be enhanced by providing a new, required,
> parameter - "max rows" (because otherwise, a select * could concievably blow
> up the rhq_config_props table with milliions of rows fo data). We could then

Right, good idea.

> make the results a list of maps (where each map consists of a row of data -
> each key in the map representing a column).

Is that really possible? How would you configure the plugin descriptor, if you don't know the list of column in advance?
Comment 7 John Mazzitelli 2014-04-04 09:56:00 EDT
(In reply to Thomas Segismont from comment #6)
> > make the results a list of maps (where each map consists of a row of data -
> > each key in the map representing a column).
> 
> Is that really possible? How would you configure the plugin descriptor, if
> you don't know the list of column in advance?

I was probably thinking that this operation wasn't a generic SQL select - if you had specific queries that are to be wrapped as operations, you would know what columns the queries returned and you could use list-o-maps. But in the case of a generic SQL operation, yes, you are right - unless you know the columns being returned, you'll have to do something else. Perhaps a single column in the descriptor to represent a row?

      <operation name="viewGenericSQLSelectResults" description="View a SQL SELECT query results">
         <results>
            <c:list-property name="rows">
               <c:map-property name="row">
                  <c:simple-property name="rownumber" summary="true"/>
                  <c:simple-property name="data" summary="true"/>
               </c:map-property>
            </c:list-property>
         </results>
      </operation>

Or, if you want to avoid having a row number column, I think you can just use a list:

      <operation name="viewGenericSQLSelectResults" description="View a SQL SELECT query results">
         <results>
            <c:list-property name="rows" />
         </results>
      </operation>

Those are just some ideas.
Comment 8 Thomas Segismont 2014-07-09 11:07:02 EDT
Fixed in master

commit fb9f14d0fcd552b72d7347521e252b68daf167b2
Author: Thomas Segismont <tsegismo@redhat.com>
Date:   Wed Jul 9 16:59:41 2014 +0200

Introduced a new "outputFormat" paramater for the "invokeSql" operation. Values may be "formattedText" or "html". Defaults to html (which was the only supported format before).
    
Formatted text prints tables like this (select id, uuid from rhq_resource limit 3) :
    
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ id (int4) +            uuid (bpchar)             +
++++++++++++++++++++++++++++++++++++++++++++++++++++
+     10018 + eba7a118-4b46-4166-b391-7977b28e5f25 +
+     10722 + 94068e4c-1929-490c-ac8e-9d51a1a9f29c +
+     10002 + d2dbdbcb-d070-4682-b05a-2383f5d3395a +
++++++++++++++++++++++++++++++++++++++++++++++++++++
Comment 9 Heiko W. Rupp 2014-12-15 06:36:26 EST
Bulk close of items fixed in RHQ 4.12

If you think this is not solved, then please open a *new* BZ and link to this one.

Note You need to log in before you can comment on or make changes to this bug.