I didn't want to affend you, sorry. But >> but then I'd argue that you shouldn't be doing that anyway. i dont agree. This is a great technic in many cases.
>> And no it doesn't have to construct a row object if you don't want to See >> < http://search.cpan.org/~ash/DBIx-Class-0.08010/lib/DBIx/Class/ResultClass/HashRefInflator.pm<http://search.cpan.org/%7Eash/DBIx-Class-0.08010/lib/DBIx/Class/ResultClass/HashRefInflator.pm> >. Then you will get a hash, not an object. >> Yes object construction can be expensive, but its what you want most of the time. If you >> dont want objects don't use an ORM. (The 'O' there stands for Object, dontcha know.) I posted a solution which caches already constructed objects in MEMD. You get objects! Without a need to construct then every time you get data from MEMD. However DBIC::C::C will construct the same objects from DB data from cache THOUSAND TIMES, again and again - this is stupid! don't you see? You think it is normal that when you start using C::C you get more local CPU usage than without it ? (it's not about Database CPU or disk usage, only perl-side). I think it's NOT. >> Which solution? Link to archives please. somewhy i cannot find it in archives. I will repost it now.
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
