On 03.09.2007, at 16:26, Gustavo Niemeyer wrote: > >> this question is exactly the use-case :-) >> >> i can define for my application by grouping which attributes should >> be loaded together, if no group is defined it should be loaded with >> the initial getter (e.g. the primary keys) >> >> so for example if i have an overview of objects in a web-page, and >> for the selected item i have a detail view on the same page it only >> fetches the title and url for the overview items and the 'toc' for >> the selected one. another example attribute in the 'hugetexts' gruop >> would be "abstract" > > I believe that this use case is kind of covered by the API I > suggested. > 'url' and 'title' would be fetched for all of them, but 'toc' would > only be fetched for the one that touched it. > > This is the most wanted use case I think: you have a few small entries > that are commonly used, and a big one that you only need occasionally. > > The price for the flexibility of specifying precisely which entries > should > be grouped together is a more obscure API. So I'm wondering if we > should > pay that price, or if the simple API covers most cases, and creates > only > a small overhead in edge cases. >
if we have somekind of grouping we would also have a solution for the "fetch only primary-keys in referencesets" use-case. currently it selects all fields for getting the result, without knowing if the object is already cached. with only a lazy keyword this cannot be done. > -- > Gustavo Niemeyer > http://niemeyer.net -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
