If these are episodes that follow one another, as they might in a production schedule, an interesting variant of this list might be the predecessor and successor links that you'd need to fill in a production graph of production. In other words, Episode 1 might have Episode 1a and Episode 2 as successors. You might want to store the graph, which could be fed to a production script or to a group of users to give them the expected time of production.
Bruce b. On Wed, Jan 18, 2012 at 1:27 PM, Nguyen, Ricky <[email protected]> wrote: > Hi all, > > Suppose I wanted to store a list of episodes in metadata. An episode has 2 > properties: start time and end time. I can think of 2 ways to do this: > > 1) use sub-metadata groups > <key>Episode/1/start</key> > <val>2011-01-15</val> > <key>Episode/1/end</key> > <val>2011-01-16</val> > <key>Episode/2/start</key> > <val>2011-01-17</val> > <key>Episode/2/end</key> > <val>2011-01-18</val> > > 2) declare length, and follow key patterns EpStartN and EpEndN > <key>NumEpisodes</key> > <val>2</val> > <key>EpStart1</key> > <val>2011-01-15</val> > > So then the next question is, how do I write elements.xml (in FileMgr policy) > to accommodate the variable number of keys? > > And a follow up question is, how do I retrieve/use this information when > creating PGE config queries? (SQL(Format='$whatgoeshere') SELECT whatgoeshere > FROM …) > > Or maybe I just shouldn't store objects in metadata... > > Thanks, > Ricky
