You can translate the question and the replies:

Verify return results: i.e. Estimated row count. Check if base views return results (with limit clause)

Related to: Testing in Denodo
In the presentation I find at some point "Verify return results: i.e. Estimated row count. Check if base views return results (with limit clause)." As far as I can understand, the Denodo Testing Tool can perform exact match, or subset/superset match between a select query's result and a csv expected result. How can I implement an estimated row count? In addition, can you give any advice (or reference) on how to automate a bulk process to check if a set of views return results (with limit clause)? Best regards Riccardo Titton
user
02-11-2022 09:30:28 -0400
code

5 Answers

Hi, For your scenario, I would like to let you know that “Verify return results: i.e. Estimated row count” in the presentation indicates a test mainly done to check the health of the base view. The Base view health check here means whether the base view tested is in executable condition and thereby checks if the Data source is accessible(base view can be executed only if the Data source has a valid connection). Since it is just a test to check the executability of the base view, we could use a LIMIT clause to limit the number of results returned instead of returning the complete result of the base view and could see if the test passes. To test the health of the multiple base views (bulk check) you can always configure multiple queries along with their corresponding results separately in the same test file as mentioned in the example below. Then, you can run the sample file configured to test the health of the multiple base views configured in it as a single go. For example, in a sample test file you can configure various base views with their corresponding results like below, > %EXECUTION[query] { ds:vdp } select id,first_name from <database_name>.bv_student limit 2; #-------------------------------------------------- %RESULTS[data] id,first_name 1,Joe 2,Chris #---------------------------------------------------- > %EXECUTION[query] { ds:vdp } select customer_id,customer_name from<database_name>.bv_cc_customer limit 1; #------------------------------------------------------ %RESULTS[data] customer_id,customer_name 1,Laura You can also configure the input query and results set as a file format like below. This can be helpful for bulk validation. > %EXECUTION[script] { ds:vdp } file:<File_path>\<Filename>.vql #----------------------------------------------------- %RESULTS[csv] { type:full } file:<File_path>\<Filename>.csv **Note: The “%RESULTS[data]” results should be in the same order as the expected result for the validation to pass.** For more information refer to [Denodo Testing Tool](https://community.denodo.com/docs/html/document/denodoconnects/8.0/en/Denodo%20Testing%20Tool%20-%20User%20Manual) - User Manual. Hope this helps!!
Denodo Team
07-11-2022 04:06:56 -0500
code
Thank you for the detailed response. For views based on rdbms data sources, the order in which rows are fetched is not guaranteed and thus we can not predict which rows are returned (first row or first two rows, for example). A possible solution could be to execute `select count(*)` queries combined with `limit n` clause but I'm not able to get it working: the limit clause is ignored when using aggregation functions. A possible workaround could be to select constant values `select 1 as ok from atr001 limit 10` just to proove the view responsiveness. To test multiple views you suggest to put multiple %EXECUTION / %RESULT in the same test. Is this the only way to do the job? I hoped there was some trick to have the job done by a special view. For example to test data source status I have found the following code wich is able to return all data sources' status check: `SELECT data_source_status.data_source_name, data_source_status.status FROM get_elements() AS elements NESTED INNER JOIN ping_data_source() AS data_source_status ON (elements.database_name = data_source_status.database_name AND elements.subtype = data_source_status.data_source_type AND elements.name = data_source_status.data_source_name) WHERE (data_source_status.timeout = 15000 AND elements.input_type = 'datasources' AND elements.database_name in ('logical_datalake_fvg', 'sys_insiel') AND elements.subtype in ('jdbc', 'odbc', 'ldap', 'olap', 'sapbwbapi', 'saperp', 'salesforce'));`
user
08-11-2022 12:55:40 -0500
Hi, I would like to let you know that an aggregation function like **count(*)** and LIMIT clause would not work together as the result of **count(*)** will be only one row. Regarding the test method, I suggested in the previous reply is to check the health of the base views (that is, executability check for views). If your use case is to do a “data source status check” test then you could use the query you mentioned for Denodo data sources testing implementation (as per the Unit Test section of the presentation). In addition, you can also automate the data source check test using the Scheduler. For more details refer to [Creating a Denodo Scheduler Job](https://community.denodo.com/kb/en/view/document/Creating%20a%20Denodo%20Scheduler%20Job?category=Scheduler) Knowledge Base. Hope this helps!!
Denodo Team
09-11-2022 08:23:41 -0500
code
I have tried to put multiple %EXECUTION / %RESULT pairs in the same test file as suggested but only the first pair is executed (Windows environment with last Denodo Testing Tool version available to date and OpenJDK 11) .
user
20-12-2022 11:32:42 -0500
Hi, I would like to let you know that by configuring a single sample file as mentioned earlier you could test multiple base views in a single go. If you are a valid support user, I would suggest you raise a support case in [Denodo Support site](https://support.denodo.com/) where an engineer could assist you further with your scenario. Hope this helps!!
Denodo Team
22-12-2022 07:21:22 -0500
code
You must sign in to add an answer. If you do not have an account, you can register here