[Mono-list] Review of mono's ADO.NET

[Francisco Figueiredo Jr.]

On Tue, 2003-05-27 at 18:03, Reggie Burnett wrote:

 >> Marco
 >>
 >> Though I haven't had a lot of time lately to update it, I have been the
 >> general maintainer of the MySQL provider named ByteFX.Data.  It is 
pure C#
 >> and has been accepted has the replacement for the original 
Mono.Data.MySql
 >> provider (which used libmysql.so)


Hi Marco, I hope you don't mind I answer some of the questions which 
also apply to Npgsql, a data provider for Postgresql which works on Mono 
and also in MS runtime. Thanks Daniel Morgan and Mono Team, it was 
accepted as one provider for Postgresql on Mono.



 >What're the motivations that conduced you to implement a provider in
 >pure C#?

The main motivation was to work with a type of programming I like most: 
middleware software (I mean, any software piece which is not directly 
related to user application but in its infrastructure) and the 
opportunity to implement a protocol.
Also, there is the dependency issues. IMHO, with the 100% managed 
provider you don't have to worry about .so/.dll files. I mean, I looked 
at Java model, and I think the model 4 drivers are much more flexible 
and so, I tooked the same approach when developing Npgsql.

 >Isn't it more difficult to mantain than the wrapper over
 >libmysqlclient.so?

I think that at first it could be more difficult. As you have to do all 
the work which already exists in the .so/.dll. But once you did the base 
code, things start to become less harder.


 > Is the right man power allocated for this project?

I think so. At gborg we have already some good guys helping and here at 
Mono we got more good guys too.

 > What kind of maturity has MySQLNEt reached?

Npgsql will be short in the 0.5 version (I wil be doing a new release 
soon). It already supports a lot of expected functionality and support 
for most common datatypes (bool, int2, int4, int8, timestamp, text and 
numeric). It allows you to work with datasets, the dataadapter allows 
you to select, insert, update and delete data. you have transaction 
support and md5 authentication. There are many bugs yet, and many 
features missing as connection pool, support for user data types, but I 
hope we can get it working soon. :)




In another mail Marco asks:

 >But what I wanna know is: is it really faster than the wrapper?
 >And if yes, does the gap between them justifie the effort of mantaining
 >a native provider?

I didn't do this comparison. But at long time, I think it could be as 
fast as or faster, as we would not use managed<->native code calls and 
the jit would allow us to get a performance close to native code.

Thanks for attention, and please let me know if I said anything wrong.


-- 
Regards,

Francisco Figueiredo Jr.

------
"My grandfather once told me that there are two
kinds of people: those
who work and those who take the credit. He told me
to try to be in the
first group; there was less competition there."
- Indira Gandhi