Search dialog with per-track indexing?

[bbimber]

I have a jbrowse 2 session where my config contains a GFF track. This track was indexed standalone using "jbrowse text-search --file xxxx.gff". When I type into the search box i get the expected typeahead. When I pick a feature and the dialog pops up, i get:

The results are valid, but is there a reason track is "N/A"? I'm guessing maybe this has something to do with aggregate indexes (which need to be aware of track), and per-track indexes? The code must "know" the track for these results though?

[cmdcolin]

We will probably want to clarify the docs for this. I believe you can use the filename that you passed to --file as the trackId e.g.

If you use --file volvox.sort.gff3.gz

Then make the trackId on this track volvox.sort.gff3.gz

[cmdcolin]

conceptually that is true, but internally, our code treats per track indexes the same as aggregate indexes, so it expects that the track id on the track to match what is in the index, and for --file, it autoassigns a trackid to the index

we could possibly reconsider this but it is how the ship sailed in the v1.4.4 release

[bbimber]

OK, this is not exactly a deal-breaker.

Question then: could we place a trackId property on the searchConfig object? If present, could the code just assume 100% of results from this adapter are from this trackId?

[cmdcolin]

I could look into this possibility...it does seem like it would be intuitive. the text-index tool could also output a little config snippet to recommend to the user also

[bbimber]

I dont know the guts of jbrowse well enough, but does whatever code parses the search config object have access to the owning track? if the search config is a child of a track (as opposed to an actual aggregate search index), could code automatically inject a "defaultTrackId" property into it? This would avoid a person ever needing to specify that? And then the code that retrieves search results would either take the trackID of the search result (if provided), or fall back to the defaultTrackId property (if specified)? Whatever the precise implementation, this just seems like something the code ought to be able to translate

[cmdcolin]

I created a issue in #2344 to try to keep track of this...would have to dig into it a lil bit to see