: > Attempting to enumerating : > all of the values for a field could be dangerous : : We do it for faceting :-) But we don't drag it all into memory at once...
i ment trying to return them all to the user at one time ... even if we decreased the server side memory usage risk my supporting Iterators in the OUtputWriters, we could still wind up slammingthe client with a large reply (theoretically: an infinite list) basicly i'm just arguing that we design the API to have a build in "limit" concept, and default it to something managable 9the same way we do for term based facet counts) : Adding a start and end (like a range query) is a great idea! oh yeah ... i hadn't considered an "end" ... just a limit, but it would be trivial to support both. : Perhaps adding Iterator or Iterable to the list of supported types in : TextWriter would be a nice general way to go. yeah ... Iterable would probably make more sense since it's the more generic API and would allow people to pass truely "lazy" objects to the SolrQueryResponse (where the iterator() method does the initialization work) ...that seems like a seperate (but related) issue to having an easy way to acces Term/Field stats. -Hoss
