Yeah, "width" was just a nice complement to "depth", but I agree with you that it's not as inuitive as it could be. Another option that occurred to me after sending my prior message was get/setCollectionFetchSize. I think it's good, and as long as people can generalize from collection.size() to map.size() and array length, it works for me. It certainly makes it obvious that it applies to collection-like thingies, yes?
The question still remains as whether or not to use the "max" prefix on both this property and the fetch depth --matthew >-----Original Message----- >From: Wes Biggs [mailto:[EMAIL PROTECTED] >Sent: Thursday, January 26, 2006 7:29 AM >To: 'JDO Expert Group' >Cc: [email protected] >Subject: Re: FetchPlan's fetchSize property: better name proposal > > >Matthew T. Adams wrote: > >Hi Matthew, > >I don't think "fetchWidth" is particularly self-documenting; >the "width" >of a collection/array is not terminology I'm familiar with, >and I would >imagine it would play the same way to most developers. > >Perhaps something involving "limit" might be clearer to those familiar >with the SQL pseudo-keyword. > >Wes > > >> Hi all, >> >> As I was reading through the 2006-01-03 version of the spec >along with >> Craig's most recent FetchPlan proposal (subject "RE: [IMPORTANT] >> Fetch-depth"), I kept getting confused between the current fetchSize >> and proposed maxFetchDepth properties on FetchPlan. There is only a >> small mention in section 12.7 that fetchPlan only applies to "the >> number of instances of multi-valued fields", meaning collections, >> maps, and arrays. The javadoc for set/getFetchSize in the spec says >> nothing about multi-valued fields explicitly, and the Apache JDO >> source javadoc for the API says even less. >> >> I would prefer that the API itself be more self-documenting, so I'm >> suggesting that we rename the fetchSize property to include >something >> about the fact that it applies to collection and is not the same as >> maxFetchDepth, further, that is the logical complement to depth. >> Taking both of these into consideration, I would suggest >> fetchCollectionWidth, "Collection" for multivalued fields, >"Width" to >> distinguish it from maxFieldDepth. However, I don't really >like that, >> since we're talking about maps and arrays as well as >collections, and >> I think "width" is sufficient to distinguish it from depth, even >> though it doesn't have the "max" prefix. >> >> So........... >> >> My recommendation to make the API more self-documenting is to change >> fetchSize to fetchWidth, so as to clearly show that is the >complement >> of maxFetchDepth in Craig's proposal. The small educational issue >> that "width" refers to size for collections/maps & length >for arrays. >> If you envision a detached graph starting with the root >object at the >> top and descending downward, it becomes even more obvious. >> >> The only remaining question is whether to remove the "max" prefix in >> "maxFetchDepth", making "fetchWidth" and "fetchDepth" even better >> complements. >> >> Craig, perhaps a negative vote on changing the current "fetchSize" >> property to "fetchWidth" and the proposed "maxFetchDepth" to just >> "fetchDepth" would be good, but it's my suggestion. I'll leave that >> to you, fearless leader. >> >> --matthew >> >> *Matthew T. Adams* >> Corporate Technical Advisor & Senior Consultant >> Mobile: +1 253 732 1051 >> Phone: +1 206 331 3833 >> Fax: +1 815 331 0952 >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> P.O. Box 24163 >> Federal Way, WA 98093 >> www.xcalia.com <http://www.xcalia.com/> >> >> >> Xcalia makes implementing SOA easy with agile business >intermediation >> software that combines heterogeneous data with services to easily >> develop and deploy transactional composite applications. >Enterprises >> can quickly respond to changing business requirements and >dramatically >> reduce the costs of data access and service integration. >> > > >
