[Mondrian] Refactor to change Member[] by List<Member>

Luis F. Canals luis.canals at stratebi.com
Tue Nov 13 15:58:26 EST 2007

Hash: SHA1

Uppps, sorry, Will, you're absolutly right!

I made a mistake: when refering to SqlTupleReader.getMember I wanted
to say "SqlTuple.readTuple".
And I agree with you, looking at the Target inner class to manage
results in an incremental way. Maybe using ITERABLE Richard's class.

Thanks, thanks a lot.

- - luis

Will Gorman wrote:
> After doing a quick search on SqlMemberSource.getMembers(), Luis's
> proposed changes shouldn't conflict with the work I'm doing. 
> Digging into it, I don't see where in Mondrian that method is called for
> the SqlMemberSource class.  I see that it is called in RolapCube to get
> the measures, but never for any other purpose.
> While I agree that this should be moved to a list, I don't know if this
> code is causing performance issues.  I suggest looking at the
> SqlTupleReader.Target class for where the issues you are seeing may be
> occurring.
> Hope that helps!
> Will
> On Tue, 2007-11-13 at 11:22 -0800, Julian Hyde wrote:
>>  > Luis Canals wrote:
>>> After taking a look at SqlMemberSource, we have discovered that all
>>> elementes from a ResultSet from a JDBC query are loading into memory
>>> and stored into an array of Member objects....
>>> As we are wanting to deal with very very very big dimensions, the
>>> first thing we need is not to overload the memory, so we are thinking
>>> of changing the type returned  by SqlMemberSource.getMembers from a
>>> Member[] to a List<Member> to be able to change it, in future, to a
>>> more intelligent List supported by an Iterator which takes elements
>>> from ResultSet non demand.
>>> Yes, we know this is going to move us to change a lot elements into
>>> code, but using a List or an Iterator instead of an array of Members
>>> is, in almost all places, a better approach.
>>> We would like to know your oppinions and suggestions.
>> Sounds like a good idea. Further, I have found that passing in a list is
>> often better than returning a list, because this way the caller gets
to have
>> a say how the list is represented; and can easily make multiple calls and
>> append to an existing list.
>> That said, I think Will is making some sweeping changes in that area which
>> he has not yet checked in. Will, please comment whether Luis's proposed
>> change is likely to conflict with your pending change. If so, I will ask
>> Luis to make the change only after you have checked in.
>> It is possible that this change affects public APIs. Please post a summary
>> of any changes to public APIs (or which people might conceivably have
>> implemented/overridden) after you have made your change. I will add
this to
>> the release notes.
>> When you have completd this API change and come to use novel
>> of lists, note that Richard Emberson has done some work to (a) use
>> memory-sensitive lists, and (b) use iterators. Please refer to his
work and
>> use the same data structures if possible.
>> Julian

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Mondrian mailing list