Error on /services/v1_1/chromosome/ when multiple chromosome with the same name

[abretaud]

Hi, Playing with some test data and my docker image, I get this 500 error on the /services/v1_1/chromosome/ url when there is multiple chromosomes with the same name but from different organisms:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 132, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/views/decorators/csrf.py", line 58, in wrapped_view
    return view_func(*args, **kwargs)
  File "/opt/gcv/server/services/views.py", line 70, in wrapper
    response = view(request, *args, **kwargs)
  File "/opt/gcv/server/services/views.py", line 893, in v1_1_chromosome
    chromosome = get_object_or_404(Feature, name=POST['chromosome'])
  File "/usr/local/lib/python2.7/dist-packages/django/shortcuts.py", line 155, in get_object_or_404
    return queryset.get(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 338, in get
    (self.model._meta.object_name, num)
MultipleObjectsReturned: get() returned more than one Feature -- it returned 2!

I guess this could be fixed by adding a filter on organism_id at https://github.com/legumeinfo/lis_context_viewer/blob/master/server/services/views.py#L893 I'm not sure how to pass the organism_id when calling the service though, I guess it should be done somehow in https://github.com/legumeinfo/lis_context_viewer/blob/master/client/src/app/services/macro-tracks.service.ts#L43

[adf-ncgr]

Hi, thanks for reporting this. FWIW, in our project we have taken the position that having two chromosomes labeled the same thing (e.g. chr1) from different organisms in the same view would be super confusing to users and so we basically just make names unique by prefixing them with species codes. I can see that all projects might not want to approach things this way, but maybe it could be at least a temporary workaround for you? We have been trying to avoid the use of the numeric PKs in our service calls, and hope to keep things a bit flexible with respect to the back-end so that we're not bound to using only chado-based implementations. We can give this some more thought, though. And going to check out your dockerization work, that's exciting to see...

[alancleary]

Thanks for bringing this to our attention @abretaud. Will try and address within the month.

[abretaud]

Ok, thanks for looking into it I'd prefer to avoid having to add a species prefix to chromosome names as we use the same ids in other apps. I think it would be a nightmare to make sure the prefix is there or not depending on the app. I get the point of not using numeric PKs, but maybe using the chado organism abbr or common name column names would be more readable?

[alancleary]

GCV has changed significantly since this issue was open. Unfortunately, we're still using the same data model so this issue hasn't actually been resolved. However, the service this issue is specifically concerned with no longer exists so I'm going to close the issue. Please open a new issue if you're still interested in resolving this issue.