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.


Reply via email to