Bug 191403 - Can not filter out the level which is blank level or null level[1102]
Summary: Can not filter out the level which is blank level or null level[1102]
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.2.0   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: Future   Edit
Assignee: Wenfeng Li CLA
QA Contact:
URL:
Whiteboard:
Keywords: plan
: 192786 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-06 20:33 EDT by Tianli Zhang CLA
Modified: 2008-06-09 18:35 EDT (History)
2 users (show)

See Also:


Attachments
attached design file (24.47 KB, application/octet-stream)
2007-06-06 20:36 EDT, Tianli Zhang CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tianli Zhang CLA 2007-06-06 20:33:11 EDT
Description:
I have a report, there are some null value level, I want to filter out all the level has value. I use is not null condition. But it doesn't work. So I remember may the level is not null value but is blank value. So how can I filter out that kind of level.

Build number: 
2.2.0.v20070607-0630

Steps to reproduce:
1, Open the attached report design
2, Set a filter on STATE level using filter is not null
3, Preview

Expected result:
Able to filter out the null value or blank value level

Actual result:
No effect
Comment 1 Tianli Zhang CLA 2007-06-06 20:36:09 EDT
Created attachment 70438 [details]
attached design file
Comment 2 Jianchao Li CLA 2007-06-06 22:35:32 EDT
In our implementation, aggregation levels with null value was firstly converted to empty string, so that the aggregation procedure can be executed. This proposal was approved by the HQ. So I think it's hard for us to filter the levels with empty string value ( who's original value is null ) using "is not null" filter.
Comment 3 Jianchao Li CLA 2007-06-06 22:38:52 EDT
Anyway, you can filter them with "not equal to" filter, who's argument is "". Thanks. 
Comment 4 Lin Zhu CLA 2007-06-07 00:33:59 EDT
This would be a 2.2.1 feature. We should add support to <blank> and <null>, which are fundermentally different.
Comment 5 Jianchao Li CLA 2007-06-14 22:47:19 EDT
*** Bug 192786 has been marked as a duplicate of this bug. ***
Comment 6 Wenfeng Li CLA 2007-08-01 18:51:04 EDT
suggest to use "not equal to" "" as the filter condition for this usage.
Comment 7 Tianli Zhang CLA 2007-08-01 20:36:58 EDT
Hi Wenfeng

How does user know the value is blank? He must use the isNotNull to filter all the null value at the first time. Another case see#192786, if the value is blank, but the value list are empty, what value should user specify? Tell him to specify the ""?
I think the <blank> and <null> should be differentiated. So reopen the bug.

Regards!
Comment 8 Wenfeng Li CLA 2007-08-01 21:31:02 EDT
I agree there is difference between null and blank in database.  But to end user or consumer, it is an advanced concept.

If we were to support null concept, we need to change BIRT engine to present null value in all report items different from how blank string is presented.  (for example uses <null> to present null string, while uses white space to present blank string.

Until we have such presentation enh, blank and NULL value is the same to end user.

Before we add a complete support of null value, I suggest we always convert DB null value to blank string at the data-engine data access layer. So there is no <null> value concept exposed to the report end user.  Since there is no <null> string value in result set data, or data set data, all filtering condition should be checking if the string data is blank.  User should not need to understand or even know about the concept of null string.  

Is there any UI or report design exposes the <null> string concept to end user in 2.2.0?  if so, I suggest we fix those places to hide the null concept but treating both null string and blank string as if it is a blank string.

In short, we assume that user does not need to know if a string is null or is blank, we assume that most usage case does not need to differentiate them. 

I agree we shall keep this bug open for future reference if we ever need to support null string concept in BIRT.  I would like to see more usage demand before adding this feature.