#14 Should'n need to cast ExecuteReader

closed-fixed
nobody
None
7
2004-10-22
2004-10-21
Natan Vivo
No

Some methods like SQLiteCommand.ExecuteReader return
the interface instead of the class, so you need to cast
to SQLiteDataReader everytime you call it.

in source, it shows:

public IDataReader ExecuteReader (){
return ExecuteReader(CommandBehavior.Default);
}

instead of

IDataReader IDbCommand.ExecuteReader (){
return ExecuteReader();
}

public SQLiteDataReader ExecuteReader (){
return ExecuteReader(CommandBehavior.Default);
}

there are other methods that are implemented this way,
but i'm late and i can't check all of them right now.

But you should take a look at this.

Discussion

  • Natan Vivo

    Natan Vivo - 2004-10-21
    • priority: 5 --> 7
     
  • Alexander Gavrilov

    Logged In: YES
    user_id=1000441

    Why do you need to cast to SQLiteDataReader? What advantages
    do you gain from SQLiteDataReader? My advice: use
    IDataReader and forget about SQLiteDataReader.

     
  • Alexander Gavrilov

    • status: open --> closed-rejected
     
  • Natan Vivo

    Natan Vivo - 2004-10-22
    • status: closed-rejected --> open-rejected
     
  • Natan Vivo

    Natan Vivo - 2004-10-22
    • status: open-rejected --> open
     
  • Natan Vivo

    Natan Vivo - 2004-10-22

    Logged In: YES
    user_id=432843

    Why? I can tell you why...

    1. Because internally YOU return a SQLDataReader

    2. Because EVERY official DataProvider works this way...
    SQLCommand returns an SQLDataReader, OLEDBCommand returns an
    OLEDBDataReader, PostgreSQL data provider works this way,
    mysql data provider works this way, every mono namespace
    works this way...

    3. and because YOU work this way if you didn't notice... You
    just forgot to make it in some cases...

    In YOUR code in SQLiteConnection:

    IDbCommand IDbConnection.CreateCommand ()
    {
    return new SQLiteCommand ("", this);
    }
    public SQLiteCommand CreateCommand ()
    {
    return new SQLiteCommand ("", this);
    }

    Why don't you return an IDbCommand here so?
    If you really don't want to fix this, ok... but don't say
    that it's right.

     
  • Alexander Gavrilov

    Logged In: YES
    user_id=1000441

    Alright, I can add functions returning SQLiteDataReader. But
    my question is still valid: What do you gain using
    SQLiteDataReader instead of IDataReader? I see only
    disadvantage here: your code becomes provider-dependent. If
    you'll decide later switch to another database or provider,
    you have to change all encounters of SQLiteDataReader. If
    you'll use IDataReader, you don't have to change anything.
    Our company built the web application which can use MS SQL
    Server or SQLite as a backend. And the only place I need to
    change is the creation of the connection object:
    SQLiteConnection or SQLConnection. Everything else uses
    interfaces.

     
  • Natan Vivo

    Natan Vivo - 2004-10-22

    Logged In: YES
    user_id=432843

    You can gain a lot so as I, just see the possibilities. In
    the SqlClient namespace, many objects implement more
    functionality than IDb interfaces obligate them to.
    SqlCommand implements IDbCommand but has a ExecuteXmlReader
    method. OracleDataReader has a method called GetOracleBinary
    that retrieves specific type from a column.

    The fact that you implement an interface only means that you
    must provide at least that functionality, not that it`s all
    your object will ever do.

    Internally you still return an SQLiteDataReader and even if
    you can`t think right now of any addiitonal functinality,
    it`s good to make your method return the real object, as you
    can implement other functionality in it later.

    About switching databases, i don`t think it`s a problem
    because your object is an interface anyway, so IF you realy
    need this functionality, you can use interfaces the same
    way. But in most cases, we work with very specific commands
    for each database as there are other much better ways to
    provide inter-database functionality as data access layers
    and etc.

    But in most cases SQLite is so lite that if you really need
    to change to SqlServer or Postgres, you will probably
    rewrite many things to be optimized to the specific database.

    So that`s my opinion... hope it helps.

     
  • Alexander Gavrilov

    Logged In: YES
    user_id=1000441

    Added all necessary functions into SQLiteConnection,
    SQLiteCommand, SQLiteTransaction.

     
  • Alexander Gavrilov

    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks