PostgExecute.Net 1.1.0

postgexecute.net

Lightweight wrapper around NpgsqlConnection object to facilitate simple PostgreSQL execution and data retrieval in .NET Core.

This is NOT an ORM

I repeat:

This is NOT an ORM

• There is not data conversion whatsoever. Not even DBNull.Value to regular null.

• Subseqently: there is no impedance mismatch issue.

• All read operations will serialize rows directly and only to IDictionary<string, object>> or proved function callback for each row (see bellow)

• or, even much, much better:

• All read operations version with lambda callback for each row

This opens up new flexibility options. Now you can:

• Serialize directly to structure of your choice. No need for extra transformation step. For example dictionary of instances that has key same as your database key.

• Write directly to stream, json, etc ...

Developer notes

If someone wishes to build micro-ORM Dapper style based on this code base - he or she may freely do so as long as they give proper credits/mentions and link to this repository. And if I may suggest a name - NoORM would be just perfect.

Current version works only with PostgreSQL and there are no plans for now to expand to other databases.

FAQ

You can do the same stuff in dapper. With ish the same syntax. I see no point, sorry.

Can you? I don't think you can.

For example, execute something custom provided by lambda parameter on each row iteration → https://github.com/vbilopav/postgrest.net/tree/master/PostgExecute.Net#read-callback-lambda

Example:

    var results = new List<IDictionary<string, object>>();
    await connection.Read(
        @"select * from (
        values
            (1, 'foo1', '1977-05-19'::date),
            (2, 'foo2', '1978-05-19'::date),
            (3, 'foo3', '1979-05-19'::date)
        ) t(first, bar, day)",
        result => results.Add(result));

I don't think that Dapper can do that. And that is not the point of Dapper, it is ORM, more precisely micro ORM and as such just want to serialize your results to a class instance and that's all.

Later, you can do with your list of objects whatever you please, usually some transformation into something else or write to some stream or whatever.

This allows you skip that step and do whatever you intended in first place and that way skip one iteration that would normally happen inside Dapper.

Don't get me wrong, Dapper will still be faster for plain serialization to your IEnumerable<T> because lambdas aren't fast and Dapper also has internal row caching. But with this, as I said you can skip at least one results iteration.

The other point of this project is that it is part of larger solution intended to work closely with PostgreSQL and as such:

• it works with NpgsqlConnection, not with IDbConnection interface as dapper because i wanted to make it as close to PostgreSQL as possible. And also System.Data; is going to be redesigned soon.

• I want to keep number of external deps as low as possible.