Custom track database: Difference between revisions
From genomewiki
Jump to navigationJump to search
No edit summary |
No edit summary |
||
Line 26: | Line 26: | ||
<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. | ||
# It might be a lot easier to keep the old system in place because the extra processing involved with a DB source of data could be handled by a new field in the customTrack structure to specify the DB source. All the exception handling for this new field is somewhat already in place everywhere because this structure is already used everywhere to fetch data for a custom track. |
Revision as of 21:36, 21 April 2006
Custom Track Database
Ideas:
- Conservative
- Keep the existing system, merely add a new keyword to the track definition line,
- 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:
- 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
- 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.
- 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.
- It might be a lot easier to keep the old system in place because the extra processing involved with a DB source of data could be handled by a new field in the customTrack structure to specify the DB source. All the exception handling for this new field is somewhat already in place everywhere because this structure is already used everywhere to fetch data for a custom track.