We have a need to limit the rows axis to specific members:
xmlaDataSource.Rows = DataSourceBase.GenerateInitialItems([Date].[Calendar]{[Date].[Calendar].[Date].&[20080702]}");
Unfortunately, this causes a change in behavior within XmlaDataSource.UpdateHierarchiesCollection whereby the entire dimension hierarchy is retrieved instead of just a single level. Looking at the code it seems like the design approach in this case is to fetch the hierarchy and then apply this "pre-filter" after the dimension results are returned.
The associated performance impact is severe -- in the dimension we are working with there is still no response after 10 minutes, whereas without the member value it is a few seconds.
It would be wonderful if Infragistics can address this issue! It's a severe limitation for us and I expect others.
If that is not feasible in the near-term, I still need to resolve it for my own purpose. My approach is to add an event handler for InitXmlaMethod and modify the MDSCHEMA_MEMBERS RequestType to add a MEMBER_UNIQUE_NAME restriction for the member value:
void xmlaDataSource_InitXmlaMethod(object sender, InitXmlaMethodEventArgs e) { var discoverMethod = e.SoapMethod as XmlaSoapMethodDiscover; if (discoverMethod != null) { if (discoverMethod.RequestType == "MDSCHEMA_MEMBERS") { discoverMethod.Restrictions.Add("MEMBER_UNIQUE_NAME", "[Date].[Calendar].[Date].&[20080702]"); } } }
Looking at the request and response in Fiddler, I see that this works well.
However, this change causes the following Execute request to generate a malformed statement.
Below is what the statement looks like without adding the restriction. Bolded is what is omitted from the statement when the restriction is added.
SELECT
NON EMPTY
{{[Date].[Calendar].[All Periods]},
{[Date].[Calendar].[All Periods].Children},
{[Date].[Calendar].[Calendar Year].&[2008].Children},
{[Date].[Calendar].[Calendar Semester].&[2008]&[2].Children},
{[Date].[Calendar].[Calendar Quarter].&[2008]&[3].Children},
{[Date].[Calendar].[Month].&[2008]&[7].Children}}
DIMENSION PROPERTIES
CHILDREN_CARDINALITY
,PARENT_UNIQUE_NAME
ON COLUMNS
FROM
(
[Date].[Calendar].[Date].&[20080701] ON COLUMNS
FROM [Adventure Works]
)
WHERE ([Measures].[Internet Sales Amount])
I appreciate your assistance with working through this difficulty.
Thanks,
Gary
Hello Gary,
Performance optimization and reducing of the response size has been determined to be a new feature request. I have sent your feature request directly to our product management team. Our product team chooses new feature requests for development based on popular feedback from our customer base. Infragistics continues to monitor application development for all of our products, so as trends appear in requested features, we can plan accordingly. Your reference number for this is FR14172.
Please let me know if you need any additional information on this.
I am not sure why your Execute statement looks different than mine. However, I realize that my explanation of the root issue wasn't very clear in the last post. The problem is not with the Execute per se, it is with the preceding Discover request with RequestType MDSCHEMA_MEMBERS. This is requesting the entire hierarchy. The size of this response is what is causing the performance issue.
Even if we use the single level [Date].[Date] hierarchy, it is still a huge response because we have dates for 100 years. We have a similar issue with other dimensions, but I am focusing on this one because you can test it against the Adventure Works cube.
Hope that clears it up.
Hi Gary,
Could you list the steps giving this result? I have put similar configuration for xmla data source
Rows="[Date].[Calendar]{[Date].[Calendar].[Date].&[20020409]}"
Measures="Internet Sales Amount"
And here is my xmla execute result:
Thanks,Plamen.
Hello Plamen,
I am referring to the XMLA Execute statement:
The goal is to be able to use the XmlaDataSource to query data without the side effect of loading complete dimensions.
When the Rows or Columns property is initialized with filters (individual member values), these filters are not included within the Execute statement, but are instead applied as "pre-filters" on the results that are returned.
To support this approach, the entire hierarchy or the entire level of applicable dimensions are loaded, which causes a performance issue on dimension levels with a large number of members.
When we apply filters we are reducing the number of applicable members from a large number to a small number. We would like the XmlaDataSource to not have the overhead of querying the large number of members when only a small number are needed.
Hopefully this makes sense, but please let me know if you need more information.
Regards,
Could you provide us with more information about what filter requirements you mean saying:
"Currently, Infragistics does not pass the filter requirements into the query"
Thanks.
Plamen.