> From: "Martin Jericho" <[EMAIL PROTECTED]> > > Thanks Scott, I did see your reply to Anmol, but I'm afraid this isn't the > answer I'm looking for. > > Having even 500 records in memory at one time is still a very bad thing to > do, and retrieving smaller chunks using LargeSelect is low level complexity > I really don't want to have to think about. It also impacts performance > because it would require a new query with every chunk instead of a single > query for the whole list. I'm not showing the million records to the user, > I'm doing batch processing on the server. > > I am amazed that no-one else has had this problem before. I'm even more > amazed that the developers designed it with such a fundamental flaw in the > first place. I'll give them more credit than to suggest that they don't > understand the issue, but the only alternative is that it was never intended > to be used in an industrial strength application. > > I am willing to implement some sort of workaround if there a plans for a fix > in the very near future, but if not I will be forced to use something else, > which of course is something I would really like to avoid. Considering that > a fix would be very straight-forward to implement, I don't think it's > unreasonable to expect it before the next beta. > I guess you have to look to the fact that torque grew out of turbine which is a web application framework. The requirements for a batch processing system are quite different from a web application that is obviously going to be more interested in dealing with user consumable chunks of data. I believe there is an obscure API that may do what you need to do - JDBC ;-).
It will be interesting to hear if anyone has a better alternative. Cheers, Scott -- Scott Eade Backstage Technologies Pty. Ltd. Web: http://www.backstagetech.com.au -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
