Bug 15837 - Consider caching to reduce excessive DBIC class instantiation for simple relationships
: Consider caching to reduce excessive DBIC class instantiation for simple rela...
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: unspecified
: PC Debian Linux
: -- normal (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-05 08:34 UTC by Alan Young
Modified: 2011-11-06 23:24 UTC (History)
1 user (show)

See Also:
Category: Task


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Young 2010-03-05 08:34:01 UTC
Relationships such as Track->album, Track->primary_artist and a few others get evaluated repeatedly around browsing an album, playing it, or a track from it, and  other operations associated with play and status queries. These relationships all use the primary key of the target object. Instantiating DBIC object instances (Album and Contributor in the examples above), even when the underlying data is cached by the DB, can be expensive. It may be beneficial to use some sort of caching, either provided by DBIC or self-implemented.
Comment 1 Alan Young 2010-03-31 01:58:56 UTC
It might be that using the DBIC cache mechanism has some legs. For example, in Track:

	$class->belongs_to('album' => 'Slim::Schema::Album', undef, {cache => 1});

But I have also seen the following statement: "..., caching works at the ResultSet level.  Any relationship
accessor on a Row object won't know about the cache." Further investigation required.
Comment 2 Alan Young 2011-11-06 23:24:15 UTC
Unassigned bugs cannot have a priority.