Can't map Booleans from native SQL queries with Code First, EF 6, ODAC 12c R3 (Beta 2)

Question

We're using Code First, EF 6, ODAC 12c R3 (Beta 2). When I use LINQ-to-Entities, I can map NUMBER(1) to Boolean fields as documented here: https://docs.oracle.com/cd/E56485_01/win.121/e55744/entityDataTypeMapping.htm#ODPNT8300
<oracle.manageddataaccess.client>
  <version number="*">
  <edmMappings>
    <edmMapping dataType="number">
      <add name="bool" precision="1"/>
      <add name="byte" precision="3" />
      <add name="int16" precision="4" />
      <add name="int32" precision="9" />
      <add name="int64" precision="18" />
    </edmMapping>
  </edmMappings>
  </version>
</oracle.manageddataaccess.client>
So far, so good:
    [Table("USER_PROFILE")]
    public class UserProfile
        [Key]
        [Column("LOGIN_ID", Order = 1)]
        public string LoginId { get; set; }
        [Column("IS_SUPER_USER")]
        public bool? IsSuperUser { get; set; }
var query = db.UserProfiles.Take(20);
However, when I try to map to the same class from native SQL, I get an exception:
// The real query is much more complex. This is just an example.
private const string AllProfilesSql = @"
            SELECT login_id AS LoginId, is_super_user AS IsSuperUser
            FROM user_profile
var query = db.Database.SqlQuery<UserProfile>(AllProfilesSql).Take(20);
>The 'IsSuperUser' property on 'UserProfile' could not be set to a 'System.Int16' value. You must set this property to a non-null value of type 'System.Boolean'.
Do you know any solutions or workarounds for this? Is it a bug?

Answer 1

Hmm, a feature request is possible; however, I'm not sure how feasible it would be to implement (if it is possible at all) in this scenario.
The challenge is that when using SqlQuery like this, EF calls into our override of the ExecuteDbDataReader method in OracleCommand (via System.Data.Common.DbCommand.ExecuteReader). That in and of itself is not an issue it's just that we don't know that this call is from EF and so we should use the EDM mappings from the configuration. In a "normal EF" scenario we know the call is from an EF "source" so can respond accordingly and perform the mapping.