Hi Davide, > I also recommend to keep data on an alternate location and just load > tracks when needed. Unfortunately there are users with hundreds of > tracks that need to be reordered once loaded.
The reordering sounds at least as painful as the reloading. There is a way to prevent having to reorder in the future: add priority=1 to the end of the custom track file's "track ..." line for the topmost track, priority=2 to the "track ..." line for the track to appear immediately below that, priority=3 for the next and so on. The priority numbering overrides the order of custom tracks in the input. The numbers do not have to start at 1, and can be floating point, which helps when inserting new tracks into an existing order. It's tedious editing, but reordering on the config page is tedious too, and editing has to be done only once (as long as the desired order stays the same and doesn't conflict between). > BTW, is there some documentation about how session and user contents > are stored? http://genomewiki.ucsc.edu/ has bits and pieces: * Cookie_Session briefly explains the relationship between hgsid (indexes hgcentral.sessionDb) and the hguid browser cookie (indexes hgcentral.userDb). (Not to be confused with the Sessions feature which uses yet another hgcentral table, and genomewiki's cookies!) * Using_custom_track_database describes most major components of the custom track loading, storing and cleaning system. It does not describe our bigDataUrl-handling code (udc) and storage (on our system, relative to cgi-bin the hg.conf setting is "udc.cacheDir=../trash/udcCache"). But it was not the udc code that caused the loss of your users' custom tracks, it was the custom track error-handling code which Galt is fixing. Beyond genomewiki, kent/src/hg/makeDb/doc/$db.txt and kent/src/product/README.*, implementation documentation consists of genome list emails and... the source code. Sorry about the inconvenience to your users and thanks for prompting us to fix the problem. Angie ----- "Davide Cittaro" <[email protected]> wrote: > From: "Davide Cittaro" <[email protected]> > To: "Jennifer Jackson" <[email protected]> > Cc: [email protected] > Sent: Thursday, December 3, 2009 11:41:08 AM GMT -08:00 US/Canada Pacific > Subject: Re: [Genome] genome browser bug and rollback? > > Hi Jennifer > > On Dec 3, 2009, at 8:34 PM, Jennifer Jackson wrote: > > > Hello, > > > > If you have a back-up of the server that you store the database on, > your DBA should be able restore an older copy. If you only have the > input files, they will need to be reloaded. When this type of thing > happens where (we had a bad server and lost all of the Session data > earlier this year), the data was just lost. We definitely recommend > keeping copies of the input files in a central, backed-up, location if > they are critical to a project. This is true for data loaded into the > UCSC browser or into a local mirror. > > > > I also recommend to keep data on an alternate location and just load > tracks when needed. Unfortunately there are users with hundreds of > tracks that need to be reordered once loaded. > > > For the "why" concerning the loss of all custom track data, not just > the subset of missing server data, I will follow up with our > developers. If anyone did a cart-reset, that would clear custom > tracks. Maybe this was done when you deleted the old data? Of if the > cleaner script was run, that would remove it all, too. > > > AFAIK they were only browsing data (hgTracks) > BTW, is there some documentation about how session and user contents > are stored? > > > d > /* > Davide Cittaro > > Cogentech - Consortium for Genomic Technologies > via adamello, 16 > 20139 Milano > Italy > > tel.: +39(02)574303007 > e-mail: [email protected] > */ > > > > _______________________________________________ > Genome maillist - [email protected] > https://lists.soe.ucsc.edu/mailman/listinfo/genome _______________________________________________ Genome maillist - [email protected] https://lists.soe.ucsc.edu/mailman/listinfo/genome
