[Mono-list] .NET version 1.1 and 2.0

[Rodrigo Moya]

On Thu, 2002-07-18 at 20:25, Tim Coleman wrote:
> On Thu, Jul 18, 2002 at 07:14:43PM +0200, Rodrigo Moya wrote:
> > On Tue, 2002-07-16 at 22:18, Miguel de Icaza wrote:
> > > 	* ADO.NET: The database guys should chime in with their
> > > 	  comments, I am not a DB person, and I am passing along what
> > > 	  people who have built these systems before told me.
> > > 
> > the biggest problem in ADO.NET I see myself is the impossibility of using it as
> > a generic database access layer. That is, to create a connection, you have to
> > know in advance the DB server/API you are going to use, which is ok for some
> > cases but not for generic database access.
> > 
> > What I miss is something along the way the driver manager in JDBC, which allows
> > to activate a driver via an identifier:
> > 
> > DriverManager dm = new DriverManager ();
> > IDbConnection cnc = dm.GetConnection ("PostgreSQL");
> > 
> > or something similar. This would be much better than:
> > 
> > if (i_want_postgres)
> > 	cnc = new PostgresConnection ();
> > else if (i_want_sql_server)
> > 	cnc = new SqlConnection ();
> > else if (i_want_generic_but_im_not_sure_there_are_drivers_installed)
> > 	cnc = new OleDbConnection ();
> > 
> > Once you get a valid IDbConnection, you can do generic usage of the class libraries
> > (using the interfaces), but to get to that point, AFAIK, you have to know in
> > advance the DB server you'll be connecting to.
> 
> While I admit, in theory, that it is nice to have abstraction
> as to what provider you choose, I find that in practice that is
> usually not very important.  If you're developing a
> tool/utility/platform/application/whatever that uses a database, you are
> probably going to consciously choose which database you are going to use
> before you actually build the application.
> 
well, it is very useful for prototyping the application, while you write
it. That is, you might be coding the app for Oracle, but you may have to
wait for the system admin to install/set it up (as it happened to me in
my previous job). So, while you wait, you can just use the generic
abstraction and use an embedded DB, for instance.

Of course, you're right that many people will just use the specific
database they code the app for, but that's not always the case.

> Besides, it isn't all that often that your SQL is 100% portable across
> all database systems anyway, so abstracting away the provider is
> probably not all that useful.  Again, this is just in my experience;
> YMMV.
> 
yes, that's another problem in ADO.NET. SQL is not portable at all
between different RDBMS, and thus, there's another problem for doing it
generic.

In libgda, to solve that last problem, we've come up with 2 solutions.
One is the schemas, which lets you access information about all the DB
objects (tables, fields, views, procedures, etc) without using SQL at
all. The other one, still to be fully integrated, are the XML queries,
which is just a XML format for specifying SQL commands.

cheers
-- 
Rodrigo Moya <rodrigo@ximian.com>