Custom track database: Difference between revisions

From genomewiki
Jump to navigationJump to search
No edit summary
No edit summary
Line 17: Line 17:
* Incoming data stream recognizes the "db=<data type>" keyword.  Incoming data is sent to a separate file for DB loading.  DB loading is done simply by exec'ing the appropriate
* Incoming data stream recognizes the "db=<data type>" keyword.  Incoming data is sent to a separate file for DB loading.  DB loading is done simply by exec'ing the appropriate
hgLoad<data type> loader into a new table in the custom track DB.  A trackDb entry is made into the custom track DB.
hgLoad<data type> loader into a new table in the custom track DB.  A trackDb entry is made into the custom track DB.
* The DB loading could also be done merely by tossing the incoming data over to the submission mechanism mentioned below.
* Subsequent viewing is achieved by combining the custom track DB trackDb entries with the ordinary trackDb entries.  An extra field has to be added to one of our structures somewhere which will allow the appropriate database to be used when processing each track since they now come from different databases.
* Subsequent viewing is achieved by combining the custom track DB trackDb entries with the ordinary trackDb entries.  An extra field has to be added to one of our structures somewhere which will allow the appropriate database to be used when processing each track since they now come from different databases.
<li>Radical</li>
<li>Radical</li>
Line 22: Line 23:
* As mentioned in 1. above, simply combine the custom track trackDb entries with the ordinary trackDb entries to make all tracks appear the same to the processing cgi-bin programs.  The only new bit of information needed would be a DB tag for each track so the appropriate database can be used for each track.
* As mentioned in 1. above, simply combine the custom track trackDb entries with the ordinary trackDb entries to make all tracks appear the same to the processing cgi-bin programs.  The only new bit of information needed would be a DB tag for each track so the appropriate database can be used for each track.
</ol>
</ol>


<h4>Gotchas</h4>
<h4>Gotchas</h4>


It may be difficult to make tracks coming from the custom track DB simply appear as just another track, but coming from another database, because the concept of "database" for source of tracks is programmed into all the CGIs as a single global variable.  It isn't immediately obvious how this could easily be made into a switch.
It may be difficult to make tracks coming from the custom track DB simply appear as just another track, but coming from another database, because the concept of "database" for source of tracks is programmed into all the CGIs as a single global variable.  It isn't immediately obvious how this could easily be made into a switch.

Revision as of 21:33, 21 April 2006

Custom Track Database

Ideas:

  1. Conservative
    • Keep the existing system, merely add a new keyword to the track definition line,
    e.g. "db=" and handle it in a similar manner to how wiggle tracks are handled now
  2. Radical
    • Remove all existing code for custom track handling and perhaps a new system could function more like existing tracks and not need special handling all over the place.

How would it work:

  1. Conservative
    • Incoming data stream recognizes the "db=" keyword. Incoming data is sent to a separate file for DB loading. DB loading is done simply by exec'ing the appropriate
    hgLoad loader into a new table in the custom track DB. A trackDb entry is made into the custom track DB.
    • The DB loading could also be done merely by tossing the incoming data over to the submission mechanism mentioned below.
    • Subsequent viewing is achieved by combining the custom track DB trackDb entries with the ordinary trackDb entries. An extra field has to be added to one of our structures somewhere which will allow the appropriate database to be used when processing each track since they now come from different databases.
  2. Radical
    • Submission system as already developed by Andy and Mark could be used to submit custom tracks.
    • As mentioned in 1. above, simply combine the custom track trackDb entries with the ordinary trackDb entries to make all tracks appear the same to the processing cgi-bin programs. The only new bit of information needed would be a DB tag for each track so the appropriate database can be used for each track.

Gotchas

It may be difficult to make tracks coming from the custom track DB simply appear as just another track, but coming from another database, because the concept of "database" for source of tracks is programmed into all the CGIs as a single global variable. It isn't immediately obvious how this could easily be made into a switch.