On Jan 5, 2007, at 8:36 PM, John Siracusa wrote:
> On 1/5/07 11:29 PM, John Siracusa wrote:
>> On 1/5/07 10:53 PM, Neal Clark wrote:
>>> my $sql = "SELECT * FROM malware_logs";
>>> $Rose::DB::Object::Manager::Debug = 1;
>>> my $iterator = MalwareLog::Manager->get_objects_iterator_from_sql
>>> ($sql);
>>
>> Just an aside: in the case of this simple query, there's no reason
>> to use a
>> *_from_sql() Manager method.
>
> ...and I'll add that there's rarely ever a reason to use the
> *_from_sql()
> methods unless you really, really like writing your own SQL, or are
> doing
> something very fancy that requires you to do so.
Yeah, you're probably correct for my case. I should be using the
"normal" manager methods. I'm not gonna lie...I was so pumped up on
the idea of using rows in my table as objects I just dove right in
without really designing it as well as I should. I'll probably re-
think a lot of what I've done so far and back up a bit. I was mostly
really excited to use the relationships I setup, where you do like
$foreign_object = $object->foreign_table. That struck me as really
really cool (first time using ORM).
I'm generating reports based on criteria found in 3 tables. My
approach so far has been query the main table, get the results,
iterate over the results calling the foreign table link and checking
cells in that row (or variables in that object) for criteria that
relate to those tables, if that makes sense.
> (The "normal" Manager methods will also deflate/coerce/format
> "rich" query
> parameter values and can fetch columns from multiple tables using
> arbitrary-depth JOINs, whereas the *_from_sql() methods can only fetch
> columns from the primary table. So in a sense, the "normal"
> Manager methods
> are actually a bit more "fancy" than the *_from_sql() ones.)
>
> -John
yeah, that's definitely what i should be doing. i will figure out how
to use the multi-table manager calls methods to specify my query all
in one shebang.
On Jan 5, 2007, at 9:04 PM, Perrin Harkins wrote:
> John Siracusa wrote:
>> Finally, if you only want to turn this on for particular calls,
>> remember
>> that the db is an optional argument to all Manager methods. You
>> can always
>> make/get a $db, yank out the $dbh, set the attribute manually, and
>> pass the
>> $db as a parameter to your Manager calls.
>>
>> $db = My::DB->new(...);
>> $db->dbh->{'mysql_use_result'} = 1;
>> $iterator = MalwareLog::Manager->get_blah_iterator(db =>
>> db, ...);
>
> I recommend doing it this way, and turning it off after your large
> query, unless this is essentially a single user reporting database.
> When you turn on mysql_use_result and do a query on a MyISAM table, it
> will keep a read lock on the table until you finish with that
> statement
> handle. This is not an issue with InnoDB tables because they use
> multi-version concurrency control (MVCC), so readers never block
> writers.
>
> If all you use it for is reports, and you don't need to handle
> concurrent updates, then it doesn't matter and you can just leave
> it on
> all the time.
thanks for that bit of info, i had just put it in the Rose::DB
object. really just this one program needs to use it, and a lot of
other programs will end up using the library.
At any rate, I changed my loader.conf:
kern.maxdsiz="1024M"
kern.dfldsiz="1024M"
kern.maxssiz="128M"
and set that mysql_use_result variable, and its doing exactly what i
want it to do. i can select * and then iterate over every single row.
Thank everyone very much!
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
