I can certainly understand not wanting to break existing interfaces, especially if the random access is useful in some situations. It's not really clear to me how limit and offset make it useful (generally this is useful for paging, and you still don't know what is going to be at what index within a given page), but I don't generally use these features. I suppose if one of the columns was actually used to store a meaningful index and you did a query sorting on that column then the indexed access would be useful but I think that is a pretty specialized case.
The memory footprint and efficiency difference I cited was based on my own testing, but I have seen the same conclusion corraberated elsewhere. I'll see if I can it again. Cheers, Eric On Apr 21, 5:42 am, Lukas Eder <[email protected]> wrote: > Hello, > > > Just had a minor suggestion to toss out there: consider using Deque > > instead if List as the collection used by fetch operations. > > Thanks for your suggestion. Replacing List by Deque as a general > method return type would be a major API change. It couldn't be done in > a minor release - unless I'd create a new type implementing both Deque > and List. > > > Deque offers iteration (in either direction) but not the random access > > of get(int index). I don't think random access is useful for result > > sets since you're not generally going to know what a given index will > > give you. > > Generally, you're right. However, RDBMS have an advantage over true > relational models in that they can order and page their result sets. > Using SQL Server's TOP 10 clause or Postgres' / MySQL's LIMIT .. > OFFSET clauses indicates, that accessing by index can be useful in > many cases. Removing that feature from jOOQ would be a major loss of > functionality. On the flip side, ListIterator can also be used for > reverse iteration, just like Deque.descendingIterator(). > > > ArrayDeque is more efficient in both interation performance > > and memory usage. > > I'm curious about this. Looking at the JDK's source code, ArrayList > doesn't seem to have a worse memory footprint compared to ArrayDeque. > Both operate on Object[] arrays and contain two additional int fields > (size, modCount vs. head, tail). As far as iteration performance is > concerned, there are some additional range checks in ArrayList, but > comparing those smells like micro-optimisation to me. There's more > potential in optimising jOOQ's internals, in my opinion. Can you cite > a source comparing ArrayDeque and ArrayList? > > So in general, I wouldn't favour using Deque over List in the jOOQ > API. Any other opinions? > > Cheers > Lukas > > 2012/4/20 ericjs <[email protected]>: > > > > > Just had a minor suggestion to toss out there: consider using Deque > > instead if List as the collection used by fetch operations. > > > Deque offers iteration (in either direction) but not the random access > > of get(int index). I don't think random access is useful for result > > sets since you're not generally going to know what a given index will > > give you. ArrayDeque is more efficient in both interation performance > > and memory usage.
