Skip to content

[Bioc-devel] AnnotationDbi and select function

6 messages · Servant Nicolas, James W. MacDonald, Marc Carlson

#
Hi Nicolas,
On 3/12/2014 12:39 PM, Servant Nicolas wrote:
Not sure what 'GENEID' is in this context - it appears to be Entrez 
Gene. But anyway, if you use "ENTREZID" instead, it works fine:

 > symbol <- select(Homo.sapiens, names(geneGR), "SYMBOL", "ENTREZID")
 > symbol <- select(Homo.sapiens, names(geneGR), "GENEID", "ENTREZID")
Error in res[, .reverseColAbbreviations(x, cnames), drop = FALSE] :
   incorrect number of dimensions
 > symbol <- select(Homo.sapiens, names(geneGR)[1:1000], "GENEID", 
"ENTREZID")
 > symbol <- select(Homo.sapiens, names(geneGR)[1:1001], "GENEID", 
"ENTREZID")
Error in res[, .reverseColAbbreviations(x, cnames), drop = FALSE] :
   incorrect number of dimensions

Best,

Jim

  
    
#
Thanks Nicolaus!  That's a good bug.  I will work on a fix.  The reason 
why James work-around here functions is because the number of databases 
that it has to query is fewer by one.  It is also faster for this 
reason.  So when you say GENEID you mean the ids used in the associated 
txdb database which means that these have to be checked against that DB 
(and anything related to it extracted) and then merged with the results 
of the symbol information by joining on the foreign key for these two 
DBs.  So thats actually much more complex than just extracting all the 
same data from just the org package even though the end result (in this 
case) is the same.  The bug is probably happening in the associated 
merge step.

  Marc
On 03/12/2014 10:06 AM, James W. MacDonald wrote:
#
Hi guys,

Thanks for your feedbacks.
Indeed I put GENEID because it is used in the txdb database.
[1] "CDSID"      "CDSNAME"    "CDSCHROM"   "CDSSTRAND"  "CDSSTART" 
 [6] "CDSEND"     "EXONID"     "EXONNAME"   "EXONCHROM"  "EXONSTRAND"
[11] "EXONSTART"  "EXONEND"    "GENEID"     "TXID"       "EXONRANK" 
[16] "TXNAME"     "TXCHROM"    "TXSTRAND"   "TXSTART"    "TXEND"    

I will move to ENTREZID which is much faster ! 
I'm glad It could help
Nicolas

________________________________________
De : bioc-devel-bounces at r-project.org [bioc-devel-bounces at r-project.org] de la part de Marc Carlson [mcarlson at fhcrc.org]
Date d'envoi : mercredi 12 mars 2014 20:18
? : bioc-devel at r-project.org
Objet : Re: [Bioc-devel] AnnotationDbi and select function

Thanks Nicolaus!  That's a good bug.  I will work on a fix.  The reason
why James work-around here functions is because the number of databases
that it has to query is fewer by one.  It is also faster for this
reason.  So when you say GENEID you mean the ids used in the associated
txdb database which means that these have to be checked against that DB
(and anything related to it extracted) and then merged with the results
of the symbol information by joining on the foreign key for these two
DBs.  So thats actually much more complex than just extracting all the
same data from just the org package even though the end result (in this
case) is the same.  The bug is probably happening in the associated
merge step.

  Marc
On 03/12/2014 10:06 AM, James W. MacDonald wrote:
_______________________________________________
Bioc-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
#
I just checked a fix in for this bug to GenomicFeatures (which happens 
to be where the problem was).  It should percolate out to the build 
system soon.

  Marc
On 03/12/2014 02:19 PM, Servant Nicolas wrote:
#
Also,

There is nothing wrong with using GENEID the way that you initially 
did.  It was just a small bug that prevented some internal subsetting 
from working properly and that is now fixed.

It just happened that GENEID was equivalent to ENTREZID in this case.  
And that ends up making it a slower choice just because the software has 
to do more work (in case GENEID is something else). So since you know 
that these are in fact ENTREZIDs, you can take Jims suggestion as a 
short cut and thus get a little performance boost.

But it's still a less specific thing to request than GENEID (which could 
potentially be another kind of ID).  So the two things (GENEID and 
ENTREZID) are not always the same kind of thing.  They just happened to 
both be ENTREZID in *this* case.  In a different scenario GENEID from 
the associated TranscriptDb might be something like an ensembl gene ID.  
And then to use a shortcut would mean using ENSEMBL instead of ENTREZID 
to do the shortcut...

In contrast: GENEID should normally always work (but it should also be a 
tiny bit slower).

Sorry if you know all this stuff, but I think its better to be explicit 
than to say too little.


   Marc
On 03/12/2014 02:53 PM, Marc Carlson wrote: