You can also take a look at the 'strategy' package in jclouds-chef/core.

All Chef api list methods return only the name and a few more fields of
each resource. In that package you'll find the strategies used to
concurrently fetch the details of those respurces (clients and nodes four
example).
El 13/06/2013 08:03, "Koper, Dies" <[email protected]> escribió:

> FWIW, for FGCP I was looking at listing nodes with few details in list
> (whatever attributes I can get from one call to the backend) and in
> listInDetail() make several calls to the backend (three or so per node?)
> to collect all the details (password, status, public IP address, etc.).
>
> In practice, as I'm using the ComputeServiceAdapter, there is no
> listInDetail method so I'm getting all details from the backend in
> getNode using several API calls, and in listNodes retrieve the list of
> node ids and call getNode for each and aggregate those results.
> I have been considering to refactor and implement separate strategy
> classes instead of using ComputeServiceAdapter.
>
> Regards,
> Dies Koper
>
>
> > -----Original Message-----
> > From: Zack Shoylev [mailto:[email protected]]
> > Sent: Thursday, 13 June 2013 2:10 PM
> > To: [email protected]
> > Subject: lazy loading question
> >
> > I have an API call that returns a list of items currently represented
> > by a domain class. Unfortunately the list method does not return all
> > details (you get the extra details with a separate call). When a user
> > requests those extra details from the domain object, they might not be
> > initialized. What is the proper way in jclouds to lazy load them? I
> can
> > do a few different one-off solutions but wondering what is the
> consistent
> > way to handle this problem.
> > What I have found similar & existing currently in code is in the
> openstack
> > nova ServerApi, the list() vs listInDetail(). In this case the problem
> > is solved by making sure the user gets the object(s) with extra
> details
> > manually. In my case the API does not provide a way to get a
> collection
> > with detailed info through a single call, however.
> > Thanks!
>
>

Reply via email to