Ok, here's a related question, then. Subsets instead of result stepping/paging.
What if I want to return a subset of a match? For example, in my EJB-QL definition for some finder method, I use the LIKE keyword. The match may result in a Collection containing tens of thousands of matching entity beans, but I'd like to simply return ten (or some other arbitrary number). My guess is that this depends highly on the implementation - that some servers will be implemented such that a Collection of fifty thousand beans isn't that much of a performance hit, because none of them are actually instantiated until I try to use them.... so if I just pick the first 10 out of the Collection to display, that's the extent of the database hit (except for the initial find method, which presumably only returns primary keys to the CMP engine). On the other hand, returning so many keys to the CMP seems like it could be a performance hit, itself. I know there are ways (vendor specific?) to request the database itself limit the size of the return set when you are working with the database directly (i.e. BMP), but can something like that be done with CMP? Thanks, David At 09:12 AM 11/2/01 -0500, Jay Walters wrote: >Great point! Who goes to a search engine and looks through 50 pages of >results? If it's for the UI, then you need more restrictive finders >anyways. > >If it's for a bulk operation you want to try and avoid doing it using entity >beans as they aren't well suited for the task. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
