[storm] Issue with find(), group by, and Single aggregates error

[Jamu Kakar]

Hi Ian,

On Wed, Nov 10, 2010 at 1:52 PM, Ian Booth <ian.booth at canonical.com> wrote:
>>> return DecoratedResultSet(store.find(xxxx))
>>>
>>> I'll poke around and see if it works for me ie the count() and the
>>> object construction. Perhaps this sort of class should be moved into the
>>> core storm API and not just be left as a Launchpad only thing.
>>
>> We've talked about it before, but it's really a hack.  It'd be better
>> to support proper eager loading in Storm than introduce something like
>> DecoratedResultSet.
>
> Is there a roadmap for storm or some other way to see if these sorts of
> features on people's radar so to speak? DecoratedResultSet seems to be
> used in a few places in Launchpad and the use case I have been
> advocating I would think would be useful in general, plus there's the
> count and group_by issue. In other words, it does seem there's a need
> there to do "something". I'm merely curious to see if the folks setting
> the storm development roadmap agree :-)

The closest thing we have to a roadmap is the TODO file in the Storm
code base.  As far as needing to do "something", yes, we all agree
that Storm would be better with nice eager loading facilities.  A few
of us talked about it during UDS and we decided that, before
implementing something, it'd be good to write a spec describing the
changes (at least from the point of view of users) we'd make to
support eager loading.  Free has pushed a branch with an experiment to
implement basic eager loading support, which could provide the basis
for something we'd land in trunk (after discussion, we decided we want
to go a bit further than what's in the branch):

lp:~free.ekanayaka/storm/eager-loading

As far as actually doing "something", I don't think any of us is
actively thinking about or working on the problem right now.  It'd be
great if someone was willing/interested in picking up the eager
loading torch and pushing it forward, though (hint, hint ;b ).

Thanks,
J.