[Npgsql-devel] Last time for breaking changes

Francisco Figueiredo Jr. francisco at npgsql.org
Tue Sep 9 18:35:39 UTC 2008


On Tue, Sep 9, 2008 at 11:53 AM, David Bachmann
<david.bachmann at ersystems.ch> wrote:
> Hi All,
>

Hi, David!

> There are some aspect of Npgsql that annoys me for long time, and
> changing them involve some breaking changes.
>

Ok.

> As Npgsql is near to the next stable release, it's the last time for
> introducing breaking changes on public interfaces. After the release of
> 2.0 stable, public interfaces should be maintained backward compatible
> until next major release (saying 3.0).
>
>

Agreed.

>
> 1. Dependency over Mono.Security
>
> If I'm right, Mono.Security is used for handling SSL connections.
> Isn't it possible to use features of the 'System' namespace, and remove
> the dependency over Mono.Security?
>
> Doing so involve changing the following publicly accessible field from
> Npgsql.NpgsqlConnection (Because they use types from
> Mono.Security.Protocol.Tls):
>
> event CertificateSelectionCallback CertificateSelectionCallback;
> event CertificateValidationCallback CertificateValidationCallback;
> event PrivateKeySelectionCallback PrivateKeySelectionCallback;
>
>

Those events are there in order to enable user to make ssl certificate
based checking. Is there something like that on core .net libraries or
is this done automagically on other places? If the last option it
would be much better to remove from Npgsql the authentication using
server and client certificates. Or maybe I'm totally wrong about that.
:)



>
> 2. Inconstancy for OID type handling
>
> Here is a list of publicly accessible methods that either require or
> return an OID type:
>
> UInt64      Npgsql.NpgsqlCommand.LastInsertedOID
> String      Npgsql.NpgsqlDataReader.GetDataTypeOID(int Index)
> Int32       NpgsqlTypes.LargeObject.GetOID()
> void        NpgsqlTypes.LargeObjectManager.Delete(Int32 oid)
> void        NpgsqlTypes.LargeObjectManager.Unlink(Int32 oid)
> LargeObject NpgsqlTypes.LargeObjectManager.Open(Int32 oid)
> LargeObject NpgsqlTypes.LargeObjectManager.Open(Int32 oid, int mode)
> Int32       NpgsqlTypes.FastPath.GetID(string name)?
>
> And the following is used for OID type mapping:
> NpgsqlBackendTypeInfo(0, "oid", NpgsqlDbType.Bigint, DbType.Int64,
> typeof(Int64), null);
>
> As you can see, there is at least 4 types used for representing an OID.
> A unique representation should be defined.
>
>  From the PG documentation, OID type is currently implemented as UInt32.
> http://www.postgresql.org/docs/8.3/interactive/datatype-oid.html
>
> Furthermore OID is an internal type, thus it could eventually be stored
> differently in future PG versions.
>
>
> First I wanted suggest to use UInt64, but it's not CLS Compliant...
> Creating an NpgsqlOid type is certainly more appropriate.
>

I think we could keep the Int64 datatype, don't you think? It is cls
compliant and could keep the whole current range of OID. I think that
by the time postgresql oid data type is changed to some other data
type, we would be in the Npgsql5 :)


>
>
> 3. Unconventional NpgsqlTypes namespace naming.
>
> To follow namespace naming conventions, 'NpgsqlTypes' should be:
> 'Npgsql.NpgsqlTypes'
>
>

Hmmmm,

When we first started Npgsql we choose Npgsql and NpgsqlTypes
separately because it is separated on sqlclient itself.

Maybe we could maintain the separated NpgsqlTypes namespace, mark it
as obsolete and copy it to Npgsql.NpgsqlTypes or maybe change the name
to Npgsql.Types.

This way, at least for while, current binary clients wouldn't be
affected so hard and users could migrate more easily to new namespace
name.

What do you think?


> ----
> What do you think about those breaking changes?
>

I think this discussion is very welcome!
And your suggestions are very nice. We for sure should make decisions
about that.


-- 
Regards,

Francisco Figueiredo Jr.
http://fxjr.blogspot.com
http://www.npgsql.org



More information about the Npgsql-devel mailing list