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

[Marco Canini]

On Wed, 2003-05-28 at 02:17, Francisco Figueiredo Jr. wrote:
> 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.
> 
Oh really thanks!
> 
> 
>  >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.

Well, I don't see anything wrong in what you said.
In the next week i'll start to test your stuff.
Many thanks to you.

-- 
Marco Canini <marco.canini@fastwebnet.it>