On Apr 12, 2006, at 10:23 PM, wojingo wrote: One thing worth considering is the memory used faulting all those objects when your not going to actually use them. I have used the second approach with good results to optimise methods like the ones you have above. If you know that the set of active records will be a relatively small number out of potentially thousands, you should fetch and sort those that your interested in only.
If your data set is similar to what wojingo suggests, I would implement a third option, not yet discussed. I would make PositionSet an abstract entity, and create 2 subentities - InactivePositionSet and ActivePositionSet. The restricting qualifier for the entities would be active='false' and active='true', respectively. With this, EOF does all the work for you.
The only real issue, which people on the list have pointed out before, is that it's a little weird for an object to have the ability to change class/entity (when you change active to/from true/false). While I agree in principal, the performance results of this solution are extremely good. You benefit from all EOF has to offer in terms of caching, faulting, etc. You get to make use of batch faulting of relationships, so that, if you have 50 EOs and you need to get the ActivePositionSets for all of them, you can do it in one query.
The down side is, when you change the active flag, you should release your instance and invalidate the snapshot. I would not use this methodology if PositionSets changed state often.
Ken |