From: Jonathan S. <js...@pc...> - 2004-06-12 13:55:54
|
Gregory: I'm looking into this problem. It may be due to the violation you suggest. Perhaps a better work-around/solution is to maintain a cache of objects, e.g., { na_sequence_id => GUS::Model::DoTS::NASequence }. Then as you scan through your list of Similarities you can easily see if you have already processed that na_sequence_id already and readily get your hands on the object if you really want to reprocess it. Of course this is solution may require more memory, but it sounds as though you already have multiple objects in memory at one time. Note to GUS developers: I seem to remember that we have discussed this idea before, but let me float it again. Should we consider changing retrieveFromDB or adding another, similar, routine that actually returns a pointer to the (cached) object? If the object can not be retrieved from the DB then it returns undef. If the object is already loaded, it returns that object. If the object is novel, then it returns the caller's notion of the object. Here are a couple of ways to use such a method. my $_obj = GUS::Model::Schema::Table->new({ table_id => 123 }); $_obj = _$obj->uniquelyRetrieveFromDb(); if (!_obj) { die "Could not find object 123 in db."; } OR my $_obj = GUS::Model::Schema::Table ->new({ table_id => 123 }) ->uniquelyRetrieveFromDb(); if (!$_obj) { die "Could not find object 123 in db."; } Thoughts? Jonathan Schug ------------------------------------------------------------------------ --- Jonathan Schug Center for Bioinformatics js...@pc... Computational Biology and Informatics Lab (215) 573-3113 voice University of Pennsylvania, (215) 573-3111 fax 1401a Blockley Hall, Philadelphia, PA 19014-6021 |