Keyword search results don't open the matching track if not already visible #526

Closed
rdhayes opened this Issue Oct 30, 2014 · 18 comments

Comments

Projects
None yet
2 participants
@rdhayes
Contributor

rdhayes commented Oct 30, 2014

I see this in v1.11.5 (probably affects earlier versions, too).

For example, starting here:
http://phytozome.jgi.doe.gov/jbrowse/index.html?data=genomes%2FEgrandis%2F&loc=scaffold_1%3A12027001..12131800&tracks=Transcripts%2CAlt_Transcripts&highlight=

Enter "Eucgr.A00747.1" in the search box. This search term matches uniquely to a feature name in the "Low-confidence Transcript" track, but JBrowse only updates the main view panel to:
http://phytozome.jgi.doe.gov/jbrowse/index.html?data=genomes%2FEgrandis%2F&loc=scaffold_1%3A12079450..12081186&tracks=Transcripts%2CAlt_Transcripts&highlight=

Coordinates updated to center on the matching feature, but you need to enable the "Low-confidence Transcript" track specifically to view it. There is no other indication for why the main view panel is empty.

I believe JBrowse should change the visibility of hidden tracks containing features that match unique search terms (or the feature selected from a multiple search result dialog) when updating the view to the matched region.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 2, 2014

Contributor

The demo instance does automatically open the tracks when you search for a feature so something different might be happening here

see http://jbrowse.org/code/JBrowse-1.11.5/?data=sample_data%2Fjson%2Fvolvox

Contributor

cmdcolin commented Nov 2, 2014

The demo instance does automatically open the tracks when you search for a feature so something different might be happening here

see http://jbrowse.org/code/JBrowse-1.11.5/?data=sample_data%2Fjson%2Fvolvox

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 3, 2014

Contributor

Would you be able to zip up your data directory or otherwise host it with a debug version of jbrowse?

Contributor

cmdcolin commented Nov 3, 2014

Would you be able to zip up your data directory or otherwise host it with a debug version of jbrowse?

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 3, 2014

Contributor

I can confirm that I see the "CanvasVariants - mixed RNAs and CDSs" open (if hidden) to display a single match to "Apple1" in your link to the volvox demo, in both Firefox and Chrome.

Colin, I'll get back to you in email directly about access to the data dir or a debug JBrowse install, depending on which one we decide to use.

Contributor

rdhayes commented Nov 3, 2014

I can confirm that I see the "CanvasVariants - mixed RNAs and CDSs" open (if hidden) to display a single match to "Apple1" in your link to the volvox demo, in both Firefox and Chrome.

Colin, I'll get back to you in email directly about access to the data dir or a debug JBrowse install, depending on which one we decide to use.

cmdcolin added a commit that referenced this issue Nov 7, 2014

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 7, 2014

Contributor

Thanks for the update. I think what I found was that incremental updates to the name store did not properly associate the names with their corresponding tracks. From what I could tell, it only happened with incremental updates.

I made a small update that should fix the issue. Feel free to test it out.

Contributor

cmdcolin commented Nov 7, 2014

Thanks for the update. I think what I found was that incremental updates to the name store did not properly associate the names with their corresponding tracks. From what I could tell, it only happened with incremental updates.

I made a small update that should fix the issue. Feel free to test it out.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 8, 2014

Contributor

The patch I made has a sort-of-subtle bug where it doesn't calculate the hashBits property. Basically, it calls the name_store function before it's ready. I'll keep a tab on this.

Contributor

cmdcolin commented Nov 8, 2014

The patch I made has a sort-of-subtle bug where it doesn't calculate the hashBits property. Basically, it calls the name_store function before it's ready. I'll keep a tab on this.

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 10, 2014

Contributor

I made another proposed fix to this that I think resolves the issue more or less completely now

Contributor

cmdcolin commented Nov 10, 2014

I made another proposed fix to this that I think resolves the issue more or less completely now

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 11, 2014

Contributor

Hi Colin,

I applied your patch from this morning and did some tests of incremental
indexing again. I now see the correct track name in the multiple results
dialog. Hidden tracks are also now opening correctly when a search result
is found.

For others who might be using incremental indexing, this also is a further
successful test that this feature was fixed in v1.11.5. I am seeing correct
mixing of autocomplete limits for search terms from different tracks, each
one indexed separately with different parameters depending on the track
data (transcripts have default autocompletion; support tracks have
--completionLimit 0 set so that they are still searchable. For example,
BlastX aligned sequences are still searchable by full feature name, but the
names index isn't bloated with autocompletion for 5 million aligned
features).

Good work!

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Mon, Nov 10, 2014 at 8:04 AM, Colin Diesh notifications@github.com
wrote:

I made another proposed fix to this that I think resolves the issue more
or less completely now


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

rdhayes commented Nov 11, 2014

Hi Colin,

I applied your patch from this morning and did some tests of incremental
indexing again. I now see the correct track name in the multiple results
dialog. Hidden tracks are also now opening correctly when a search result
is found.

For others who might be using incremental indexing, this also is a further
successful test that this feature was fixed in v1.11.5. I am seeing correct
mixing of autocomplete limits for search terms from different tracks, each
one indexed separately with different parameters depending on the track
data (transcripts have default autocompletion; support tracks have
--completionLimit 0 set so that they are still searchable. For example,
BlastX aligned sequences are still searchable by full feature name, but the
names index isn't bloated with autocompletion for 5 million aligned
features).

Good work!

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Mon, Nov 10, 2014 at 8:04 AM, Colin Diesh notifications@github.com
wrote:

I made another proposed fix to this that I think resolves the issue more
or less completely now


Reply to this email directly or view it on GitHub
#526 (comment).

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 11, 2014

Contributor

Glad to hear! If you're interested the --workdir parameter for generate-names.pl was also fixed here #506

Contributor

cmdcolin commented Nov 11, 2014

Glad to hear! If you're interested the --workdir parameter for generate-names.pl was also fixed here #506

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 12, 2014

Contributor

Closed for now

Contributor

cmdcolin commented Nov 12, 2014

Closed for now

@cmdcolin cmdcolin closed this Nov 12, 2014

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 12, 2014

Contributor

Hi,

I've noticed that the JSON files under the names/ dir created by my
hand-patched v1.11.5 are no longer gzipped, even though I'm using the
--compress flag.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Mon, Nov 10, 2014 at 6:42 PM, Colin Diesh notifications@github.com
wrote:

Glad to hear! If you're interested the --workdir parameter for
generate-names.pl was also fixed here #506
#506


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

rdhayes commented Nov 12, 2014

Hi,

I've noticed that the JSON files under the names/ dir created by my
hand-patched v1.11.5 are no longer gzipped, even though I'm using the
--compress flag.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Mon, Nov 10, 2014 at 6:42 PM, Colin Diesh notifications@github.com
wrote:

Glad to hear! If you're interested the --workdir parameter for
generate-names.pl was also fixed here #506
#506


Reply to this email directly or view it on GitHub
#526 (comment).

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 12, 2014

Contributor

Hmm.. can you describe your process for making that happen? Was it a incremental index or no?

Contributor

cmdcolin commented Nov 12, 2014

Hmm.. can you describe your process for making that happen? Was it a incremental index or no?

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 12, 2014

Contributor

Successive commands like:

perl /bin/generate-names.pl --incremental
--completionLimit 0 --sortMem 4000000000 --verbose --tracks
--compress --out
perl /bin/generate-names.pl --incremental
--sortMem 4000000000 --verbose --tracks --compress --out

etc. where track1 gets no autocompletion limit, and track2 gets the default
autocompletion.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Wed, Nov 12, 2014 at 3:45 PM, Colin Diesh notifications@github.com
wrote:

Hmm.. can you describe your process for making that happen? Was it a
incremental index or no?


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

rdhayes commented Nov 12, 2014

Successive commands like:

perl /bin/generate-names.pl --incremental
--completionLimit 0 --sortMem 4000000000 --verbose --tracks
--compress --out
perl /bin/generate-names.pl --incremental
--sortMem 4000000000 --verbose --tracks --compress --out

etc. where track1 gets no autocompletion limit, and track2 gets the default
autocompletion.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Wed, Nov 12, 2014 at 3:45 PM, Colin Diesh notifications@github.com
wrote:

Hmm.. can you describe your process for making that happen? Was it a
incremental index or no?


Reply to this email directly or view it on GitHub
#526 (comment).

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 13, 2014

Contributor

Do you use the --incremental flag on the "initial" generation of the names store? This seems like it might cause some problems that I haven't yet debugged.

Contributor

cmdcolin commented Nov 13, 2014

Do you use the --incremental flag on the "initial" generation of the names store? This seems like it might cause some problems that I haven't yet debugged.

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 13, 2014

Contributor

Yes, we currently do include the --incremental flag for every run. I'll
test out starting a new names store without that for the first track this
afternoon.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Wed, Nov 12, 2014 at 9:40 PM, Colin Diesh notifications@github.com
wrote:

Do you use the --incremental flag on the "initial" generation of the names
store? This seems like it might cause some problems that I haven't yet
debugged.


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

rdhayes commented Nov 13, 2014

Yes, we currently do include the --incremental flag for every run. I'll
test out starting a new names store without that for the first track this
afternoon.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Wed, Nov 12, 2014 at 9:40 PM, Colin Diesh notifications@github.com
wrote:

Do you use the --incremental flag on the "initial" generation of the names
store? This seems like it might cause some problems that I haven't yet
debugged.


Reply to this email directly or view it on GitHub
#526 (comment).

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 18, 2014

Contributor

I have confirmed that switching to not using --incremental for the first
track fixes the latest problem where --compress was ignored.

After checking the source code, I'm still not sure exactly how use of
--incremental when there is no existing names dir is causing the default
settings for no compression to remain in effect. Regardless, this
modification to my script usage does result in compressed files.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Thu, Nov 13, 2014 at 12:42 PM, Richard Hayes rdhayes@lbl.gov wrote:

Yes, we currently do include the --incremental flag for every run. I'll
test out starting a new names store without that for the first track this
afternoon.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Wed, Nov 12, 2014 at 9:40 PM, Colin Diesh notifications@github.com
wrote:

Do you use the --incremental flag on the "initial" generation of the
names store? This seems like it might cause some problems that I haven't
yet debugged.


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

rdhayes commented Nov 18, 2014

I have confirmed that switching to not using --incremental for the first
track fixes the latest problem where --compress was ignored.

After checking the source code, I'm still not sure exactly how use of
--incremental when there is no existing names dir is causing the default
settings for no compression to remain in effect. Regardless, this
modification to my script usage does result in compressed files.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Thu, Nov 13, 2014 at 12:42 PM, Richard Hayes rdhayes@lbl.gov wrote:

Yes, we currently do include the --incremental flag for every run. I'll
test out starting a new names store without that for the first track this
afternoon.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Wed, Nov 12, 2014 at 9:40 PM, Colin Diesh notifications@github.com
wrote:

Do you use the --incremental flag on the "initial" generation of the
names store? This seems like it might cause some problems that I haven't
yet debugged.


Reply to this email directly or view it on GitHub
#526 (comment).

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 18, 2014

Contributor

I think I fixed the problem of using --incremental on the uninitialized hash store. Thanks for catching that problem

Contributor

cmdcolin commented Nov 18, 2014

I think I fixed the problem of using --incremental on the uninitialized hash store. Thanks for catching that problem

@rdhayes

This comment has been minimized.

Show comment
Hide comment
@rdhayes

rdhayes Nov 21, 2014

Contributor

Cool, I applied this patch as well. I can confirm that use of --incremental
for the first track of a new name store now honors my use of --compress for
the files, too.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Tue, Nov 18, 2014 at 8:53 AM, Colin Diesh notifications@github.com
wrote:

I think I fixed the problem of using --incremental on the uninitialized
hash store. Thanks for catching that problem


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

rdhayes commented Nov 21, 2014

Cool, I applied this patch as well. I can confirm that use of --incremental
for the first track of a new name store now honors my use of --compress for
the files, too.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Tue, Nov 18, 2014 at 8:53 AM, Colin Diesh notifications@github.com
wrote:

I think I fixed the problem of using --incremental on the uninitialized
hash store. Thanks for catching that problem


Reply to this email directly or view it on GitHub
#526 (comment).

@cmdcolin

This comment has been minimized.

Show comment
Hide comment
@cmdcolin

cmdcolin Nov 21, 2014

Contributor

Thanks for testing and reporting that!

On Fri, Nov 21, 2014 at 2:46 PM, Richard D. Hayes notifications@github.com
wrote:

Cool, I applied this patch as well. I can confirm that use of
--incremental
for the first track of a new name store now honors my use of --compress
for
the files, too.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Tue, Nov 18, 2014 at 8:53 AM, Colin Diesh notifications@github.com
wrote:

I think I fixed the problem of using --incremental on the uninitialized
hash store. Thanks for catching that problem


Reply to this email directly or view it on GitHub
#526 (comment).


Reply to this email directly or view it on GitHub
#526 (comment).

Contributor

cmdcolin commented Nov 21, 2014

Thanks for testing and reporting that!

On Fri, Nov 21, 2014 at 2:46 PM, Richard D. Hayes notifications@github.com
wrote:

Cool, I applied this patch as well. I can confirm that use of
--incremental
for the first track of a new name store now honors my use of --compress
for
the files, too.

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://phytozome.jgi.doe.gov

On Tue, Nov 18, 2014 at 8:53 AM, Colin Diesh notifications@github.com
wrote:

I think I fixed the problem of using --incremental on the uninitialized
hash store. Thanks for catching that problem


Reply to this email directly or view it on GitHub
#526 (comment).


Reply to this email directly or view it on GitHub
#526 (comment).

@cmdcolin cmdcolin added this to the 1.11.6 milestone Jan 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment