<div dir="ltr">Hello fellow mondrian enthusiasts,<div><br></div><div>So in my spare time, I&#39;ve been playing with the idea of pushing ranges of members into SQL predicates.</div><div><br></div><div>After some experiments, I&#39;ve quickly realized that it isn&#39;t very easy to do in most cases. I say *most* because there is one case where it becomes interesting; time.</div>

<div><br></div><div>Time has this one particularity. However you structure your warehouse, we can safely assume that time is structured as flowing forward. </div><div><br></div><div>With this assumption, I&#39;ve created a new tuple constraint called the LevelDateRangeConstraint, which can turn the outer bounds of a range of time members into SQL predicates.</div>

<div><br></div><div>There are a few caveats. It can only work if the level is based off a field of type Date or Timestamp. Anything else cannot be reliably nativized. ie. If I say ( [Time].[April] : [Time].[December] ), I get wrong results, since I&#39;ll get members by alphabetical ordering. </div>

<div><br></div><div>When we get to nativizing this into a range of members, I need to use the key and the order key, but I can&#39;t get to these unless I load all the members first, thus defeating the purpose of the optimization.</div>

<div><br></div><div>My prototype works well when a range is expressed as member keys, like so: ( [Time].&amp;[2014:01:01] : [Time].&amp;[2014:01-02] )</div><div><br></div><div>If I say ( [Time].[2014:01:01] : [Time].[2014:01-02] ), I&#39;m again expressing the range as names. My code can work around this problem, but only as long as the same SQL expression is used for the name and for the key (same column or expression).</div>

<div><br></div><div>So far I didn&#39;t get the time to write tests when the range is part of a calculated member or the slicer, but I intend to in the near future. In the meanwhile, I submit to you for review the branch called &quot;smr&quot;, originally picked because of the SmartMemberReader, where I started off.</div>

<div><br></div><div><a href="https://github.com/pentaho/mondrian/compare/smr">https://github.com/pentaho/mondrian/compare/smr</a><br></div><div><br></div><div>I&#39;ll be working on this some more in the following weeks, but so far it&#39;s looking good. The optimization really does help overall in a couple areas, not just with ranges of dates. MDX names can be turned into a tuple constraint if the name expression is the same as the key expression. That&#39;s a great help.</div>

<div><br></div><div>Anyhow. stay tuned for more later!</div><div><br></div><div>Luc</div><div><br></div><div><br></div><div><br></div><div><br></div></div>