Bug 50569 - Feature Request: Jdbc Request Sampler to optionally store result set object data
Feature Request: Jdbc Request Sampler to optionally store result set object data
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: Main
2.4
PC Linux
: P2 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-01-11 09:59 UTC by zachv
Modified: 2011-03-18 08:59 UTC (History)
0 users



Attachments
Patch for storing result set objects in internal variable (4.49 KB, patch)
2011-01-11 09:59 UTC, zachv
Details | Diff
Revised patch using Map interface (4.47 KB, patch)
2011-01-12 03:35 UTC, zachv
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zachv 2011-01-11 09:59:41 UTC
Created attachment 26475 [details]
Patch for storing result set objects in internal variable

Hi

I'm new to JMeter and needed a feature for the Jdbc Request Sampler to add the result set objects to an internal JMeter variable because the string representation of some values were problematic for me. I have written code that is sufficient for my purposes, but wondered whether anyone else would find it useful, though I am sure JMeter developers will have a wider perspective on the implications of the changes.

Basically I create a list of HashMaps where the list represents each row and the HashMap uses the column names to lookup the column value as retrieved from the getObject method on the resultset. I added a UI textbox called resultVariable in which the list is stored.

I have only added properties to the main JdbcSampleResources.properties file.

Complements on a great tool and framework to work on...
Comment 1 Sebb 2011-01-11 10:18:49 UTC
What was it that caused problems with the existing mechanism?
Maybe there's a way to address that directly - maybe not.

But in principle the patch looks like a good idea, and is optional so won't affect existing test plans.

Can you provide an example of how one would use the variables?
Comment 2 zachv 2011-01-12 03:33:53 UTC
I am using JMeter for functional testing of our messaging server, so I send a tcp request and then afterwards check the response message against a database record and this for different supported dbms.

I ran into problems comparing floating point types (floats: legacy use which I can't change). So I created the patch to see if I can get better results when working with the actual objects. It also makes it easier to write validation code outside of jmeter that I can call from BeanShell.

On review I noticed that I used:
List<HashMap<String, Object> > results = null;

Instead of the Map interface:
List<Map<String, Object> > results

So I will upload a new patch reflecting that.

Here follows an example:
-----------------------
*** Jdbc Request Sampler ***
Query:select vendor_name, vendor_balance from vendor where vendor_id = ${vendorId}
Result variable name:resultList

*** BeanShell Assertion ***
(child to the Jdbc Request Sampler)
Script:
//----------------------------------------
list = vars.getObject("resultList"); // This is a List<Map<String, Object> >
print("resultList=" + list);

map = list.get(0); // get first row results, should only be one row, Map<String,Object>
vendorName = map.get("vendor_name");
vendorBalance = map.get("vendor_balance");
if(!vendorBalance.equals(expectedBalance)) {
  Failure = true;
  FailureMessage = "TEST FAILED: vendor=" + vendorName + ",balance=" + ",expectedBalance=" + expectedBalance;
}
//----------------------------------------
Comment 3 zachv 2011-01-12 03:35:38 UTC
Created attachment 26483 [details]
Revised patch using Map interface

On review I noticed that I used:
List<HashMap<String, Object> > results = null;

Instead of the Map interface:
List<Map<String, Object> > results

So this reflects that change.
Comment 4 Sebb 2011-01-12 03:57:34 UTC
(In reply to comment #2)

> I ran into problems comparing floating point types (floats: legacy use which I
> can't change).

So was the problem due to the precision of the string version, or difficulty in comparing string representations of floats?

[BTW, floats should normally be compared using an epsilon - e.g. if (Math.abs(X - Y) <= (X / 10^7))]
Comment 5 zachv 2011-01-12 06:10:31 UTC
Sorry! I misspoke when I said this: "because the string representation of some values were problematic for me"

It wasn't the string representation, but the fact that casting from a float to a double is problematic.

The current implementation is sufficient and using an epsilon would resolve this. In trying to get an accurate picture of what was going on, I thought it would be great excuse to implement this feature which I wanted in any case.

Casting problem:
        float f1 = 333.33334f;
        double d1 = 333.33334d;
        double d2 = (double)f1;
        System.out.println(f1);
        System.out.println(d1);
        System.out.println(d2);

Results in:
f1=333.33334
d1=333.33334
d2=333.3333435058594

So d1 is not equal to d2.
Comment 6 Sebb 2011-03-18 08:59:22 UTC
Thanks, patch applied.

I changed it slightly so that the resultObject is independent of the variables, so one can have neither, either or both.


URL: http://svn.apache.org/viewvc?rev=1082897&view=rev
Log:
Bug 50569 - Jdbc Request Sampler to optionally store result set object data

Modified:
   jakarta/jmeter/trunk/docs/images/screenshots/jdbctest/jdbc-request.png
   jakarta/jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSampler.java
   jakarta/jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSamplerBeanInfo.java
   jakarta/jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSamplerResources.properties
   jakarta/jmeter/trunk/xdocs/changes.xml
   jakarta/jmeter/trunk/xdocs/images/screenshots/jdbctest/jdbc-request.png
   jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml