On Mar 27, 2007, at 3:02 AM, James Masters wrote:
> A fundamental question has occurred to me. In my legacy code, I do
> a single
> call to the database and load (for the sake of arg), an entire
> table into a
> hash right at the start. e.g. If I have a table of suppliers, I will
I do that with ~20 tables that hold data I consider 'constants'. If
this data is unchanging, there's no need to continually hit the db.
( note, i do this in a persistent environment , and i use that data
nonstop. i think its easier putting config/constant data in a db
than an xml / hash )
> 1. Iterate through my existing list and pick 'em out:
> $oldsuppliers = [];
> foreach $supplier (@$suppliers)
> push @$oldsuppliers, $supplier if ($supplier->obsolete eq 'Y');
> }
>
> 2. Use a new query:
> $oldsuppliers = get_suppliers(query => [obsolete => {eq => 'Y'}])
>
> 3. Get Rose to do 1 more elegantly in a way that I haven't yet found:
> $oldsuppliers = $suppliers->(query => [obsolete => {eq => 'Y'}]) or
> something.
> Q1: Is 3 or something like possible?
Do you mean using the cached data, or just in general --
nevertheless, it looks like a manager class call to me.
http://search.cpan.org/~jsiracusa/Rose-DB-Object-0.763/lib/Rose/DB/
Object/Manager.pm
John also added a 'find' command a few months ago to svn. I don't
know if its in release yet. it does something similar, but doesn't
cache.
> Q2: If I do 2, does Rose "magically" cache the information found in
> the
> first call so that in fact the database is not called again?
you should look at the Cached object
http://search.cpan.org/~jsiracusa/Rose-DB-Object-0.763/lib/Rose/DB/
Object/Cached.pm
BUT
For a second, I think you need to step back and think about what
you're asking for, and what rose does.
Rose builds the SQL for the db, executes it, and returns (and
possibly caches) rows of data from the DB as Perl objects.
Some of the functionality you're suggesting would require rose to
not just support wrapping the db data, but also functioning as a
database itself and performing the query options on its own internal
store.
> Q3: Which of the 3 methods is recommended?
it depends on your application.
your application will either hit a performance bottleneck from
memory , db access , or none at all. chances are it will hit none at
all.
> Q4: Which of the 3 methods is best for performance?
see above (q3)
> Q5: My database is not big (biggest table 3000 rows, suppliers
> table 50
> rows). Should I not be worrying about doing 2 database calls
> instead of 1
> because the performance hit is insignificant anyway?
>
> I would be most grateful for some pointers re. the questions
> above. I could
> ask the same set of questions but changing the second call from
> obtaining a
> list of $suppliers to obtaining a single $supplier using
> Rose:DB:Object
> instead. Do the same answers apply?
my personal advice:
a- if your suppliers change often, you shouldn't be storing the data
in a hash.
b- if your code / db is so small and simple, let it hit the db like
crazy. if something seems slow or you're causing a resource lock,
then look into caching and generally speeding stuff up.
the biggest cost with most database work is usually connecting to the
database itself , and thats greatly alleviated by persistant
connections which most environments now support. make 2 queries or
40 queries probably isn't going to make any significant difference in
your usability unless you're getting into the hundreds of requests
per second situation or have extremely complex joins.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
-------------------------------------------------------------------------
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
