I too would agree that solution 1 would be the best aproach, if size/absolute/relative are going to be offered. Object iteration would be.. nasty at best. And the straight count is limited.
Is there an easy way to extract a non-JOIN'ed query to use for these operations? I guess that we would need to issue the query with appropriate constraints/ordering but without the join information, and then store that in an array as a lookup for the size/relative/absolute functions. Theoretically it could be lazy queried and issued only when necessary, but then you could have some interesting transactional problems, so perhaps not.
Does anybody use these methods with complex objects, and how do you solve these problems?
paul
On Thu, 2002-11-21 at 14:14, Matthew Baird wrote:
unfortunately you are correct (I wrote that code) with the dependent objects and the join to load them all, the absolute, .size and .relative are all "random" unfortunately, there is no "easy" way to solve this: 1. Change the way Castor loads dependent objects (2 queries) (solves all .size, .relative and .absolute issues) 2. Change the .size, .absolute, and .relative to iterate through all objects (UGGGGG) (solves all .size, .relative and .absolute issues) 3. Change the .size to execute the appropriate count(*) (solves only the the .size problem) Maybe there is another way I'm not familiar with. I would recommend going with 1, as it is the best from a performance point of view, otherwise there really isn't a reason to put this functionality into castor, just have it in your app. m
