Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

500 server error when entering gene name in "Coordinate or gene name box" #38

Open
adelq opened this issue Mar 7, 2018 · 5 comments
Open
Assignees
Labels
Documentation Regarding to documentation and usage
Milestone

Comments

@adelq
Copy link
Contributor

adelq commented Mar 7, 2018

PHP error provided in partialNames.php:

PHP Fatal error:  Call to a member function bind_param() on a non-object in /var/www/give/html/givdata/partialNames.php on line 37

This happens for every gene name out of the box.

@adelq
Copy link
Contributor Author

adelq commented Mar 7, 2018

After debugging more thoroughly this is due to the prepared SQL query above failing with the error:

Table 'mm10._AliasTable' doesn't exist

So it seems that an _AliasTable is required for the gene name input box, but there is no documentation about this, and the only other place this is used is scripts/geneNameUpdate.py. It would be nice if more information about what columns are expected in the gene annotation tracks is documented. For example, currently, the first column is used for displaying the gene name on the track, and while the UCSC knownGene.txt and the provided knownGene.txt.gz files use the UCSC id in the first column, all the demos use the gene symbol.

@caoxiaoyi03 caoxiaoyi03 self-assigned this Mar 8, 2018
@caoxiaoyi03 caoxiaoyi03 added the Documentation Regarding to documentation and usage label Mar 8, 2018
@adelq
Copy link
Contributor Author

adelq commented Mar 8, 2018

I have rewritten the scripts/geneNameUpdate.py script in Go to import the data to avoid installing the Python dependencies for the original script, and the issue persists after importing the NCBI data, creation of the aliases table, and importing the kgXref data from UCSC separately. With all the data imported, there is no longer a 500 error in response to partialNames.php, but there is no data in the response. Will continue to debug what the issue is.

@adelq
Copy link
Contributor Author

adelq commented Mar 8, 2018

I have a semi-working search box now, at the expense of having the UCSC default gene names on the gene annotation track, but that can be fixed by adding another track with the real gene names and hiding the knownGenes track. However, the SQL query for search is extremely slow at first load.

More severely however, issue #37 occurs when opening specific genes, so I do not think this is due to the bigWig files. For instance, in another set of bigWigs that work perfectly fine at Actb, when navigating away to another gene (Fezf2), the browser hangs and is stuck in PineNode.js like in the previously reported issue.

@caoxiaoyi03
Copy link
Contributor

The <gene-coor-input> element was developed quite early (well before the alpha stage of GIVE) so the documentation and back-end support is different from most of the other elements.

Currently it depends on four tables:

  1. _NcbiGeneInfo table to get the gene description corresponding to gene symbols;
  2. _AliasTable table to convert various aliases of the genes to the official gene symbol;
  3. kgXref table from UCSC to translate official gene symbol to UCSC ids;
  4. knownGene table to find genomic coordinates for the gene symbol.

The script scripts/geneNameUpdate.py can automatically populate tables _NcbiGeneInfo and _AliasTable from NCBI public data. However, we haven't been able to document it and are working on it (including moving requirement 3 and 4 to something customizable, so it will not depend on only UCSC gene tracks) before the next release. (This is also a part of #26 so the release should fix them both.)

We saw bugs in bigWig file handling before that only happens at specific genomic regions, where the data does not meet some assumptions. It is also possible that #37 only happens when there is a specific structure in the bigWig file. Will be looking into it but if it's stuck in PineNode.js that will be the most likely reason.

@caoxiaoyi03 caoxiaoyi03 added this to the 0.3.0 Release milestone Mar 8, 2018
@adelq
Copy link
Contributor Author

adelq commented Mar 9, 2018

Understood, thanks for the background information. My rewrite of scripts/geneNameUpdate.py in Go works as expected with the GIVE-Docker container.

I'm curious what kinds of assumptions need to be met in the data, is there a particular flag or configuration change you for creating the bigWigs? Thanks.

@caoxiaoyi03 caoxiaoyi03 moved this from To do to In progress in Release preparation Mar 29, 2018
@caoxiaoyi03 caoxiaoyi03 moved this from To do to In progress in Better error handling Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation Regarding to documentation and usage
Projects
Better error handling
  
In progress
Release preparation
  
In progress
Development

No branches or pull requests

2 participants