lect()' returned 1:many mapping between keys and columns
>BRCA1
> "GO:0000151"
>
> Martin
>
> ____
> From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of James W.
> MacDonald [jmac...@uw.edu]
> Sent: Monda
;GO", "SYMBOL", multiVals="first")
'select()' returned 1:many mapping between keys and columns
BRCA1
"GO:151"
Martin
From: Bioc-devel [bioc-devel-boun...@r-project.org] on behalf of James W.
MacDonald [jmac...
Hi Hervé,
I think you make a valid point, but I am not sure it conforms to either the
historical expectations for the annotation packages, nor the expected use
case. In other words, the annotation packages have, since the beginning,
returned something that was as close to parallel to the input as
...@r-project.org] on behalf of James W.
MacDonald [jmac...@uw.edu]
Sent: Friday, November 20, 2015 5:30 PM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] Behavior of select function in AnnotationDbi
There is an inconsistency in how select() works in AnnotationDbi when a
user passes
On 11/20/2015 03:21 PM, Hervé Pagès wrote:
Hi Jim,
I think we should choose the biomaRt model, that is, duplicated are
allowed but silently ignored.
Note that this is also the SQL model. When you do
SELECT * FROM ... WHERE key IN c('key1', 'key2', ...)
There is an inconsistency in how select() works in AnnotationDbi when a
user passes in duplicated keys to be mapped, depending on if the mapping is
1:1 or 1:many. It's easiest to show using an example.
> select(org.Hs.eg.db, rep("1", 3), "SYMBOL")
'select()' returned many:1 mapping between keys
Hi Jim,
I think we should choose the biomaRt model, that is, duplicated are
allowed but silently ignored.
Note that this is also the SQL model. When you do
SELECT * FROM ... WHERE key IN c('key1', 'key2', ...)
duplicated keys don't generate duplicates in the output.
Also note that, like
