[Mono-list] Review of mono's ADO.NET
Francisco Figueiredo Jr.
Tue, 27 May 2003 21:17:01 -0300
On Tue, 2003-05-27 at 18:03, Reggie Burnett wrote:
>> 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
>> and has been accepted has the replacement for the original
>> 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
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
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.
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