Option to search by uniquename in v1_gene_to_query_track

[abretaud]

Hi,
I have some genes which have different values for name and uniquename in the chado db. Currently v1_gene_to_query_track only uses the name column, but it would be cool to be able to configure it to look at uniquename (or maybe to try both?)
For the moment, I've made an ugly env var in the docker image, but I'm not very proud of myself

[adf-ncgr]

Hi @abretaud - sorry for the slow response. I think something like this is a good idea- in our project we have skirted the issue by giving things names that are unique to serve as unambiguous labels in multigenome contexts (our uniquenames tend to be more verbose than our users care for), but per your comments on another thread it sounds like doing that could cause some other issues for you in terms of causing naming-mismatch with other applications.

At the moment, I think I prefer the approach to configure (by some mechanism similar to what you have done) a site to use one or the other (name or uniquename) in terms of what data gets transmitted about genes/chromosomes as the result of service calls, but perhaps handle searching by either name or uniquename as part of #94
(ie if a user came in with a gene identifier, we would do the conversion as
part of that process and depending on how the site was configured , but we wouldn't try to maintain the duality of names and uniquenames as part of our API)

let me know if that makes sense as far as you are concerned. and regarding not being very proud of yourself for using an ugly env var, I will let @alancleary decide what his coding aesthetic will accept, as I lost all sense of shame when it comes to coding long, long ago... :)

[abretaud]

Sorry for the (longer) delay too :)
I like the idea of including it in the reflexion in #94
As for the API, I still wonder what's the best attribute to use as names are not supposed to be unique, nor uniquenames if you don't check organism_id and type_id
For now, I'll just leave my env var stuff

[alancleary]

Hey @abretaud. Sorry we let this go unaddressed for so long. We've actually been working on a new microservices based implementation of the GCV backend that addresses this issue and many others: https://github.com/legumeinfo/lis_gcv_microservices. As such, we have not been actively developing the Django backend. The new backend is not quite ready for production but it will certainly replace the Django implementation when it's released.