Skip to main content

Npgsql 2.0.10 and NpgsqlParameter.Value


Hi all!

As you may already know, Npgsql 2.0.10 is out. Besides the usual batch of bug fixes and enhancements, this release has a new feature which needs more attention as it may give you backward compatibility problems.

What happened?

With this release, we decided to implement a property in NpgsqlParameter which returns provider specific objects, just like SQLClient does.

NpgsqlParameter now features a property called NpgsqlValue. As you may guess, when you use it, you will receive a value whose type is Npgsql specific.

Why this change?

In the past, we had a lot of problems dealing how we would handle values which are specific to Npgsql, like NpgsqlTimestamp from others which are represented in CLR, like DateTime. This situation led to cast exceptions bugs. This was the main motivation for this.

Also, we think that by implementing this we would be giving our users a much consistent way of getting values in CLR type and in Npgsql-specific type. Another benefit is that now Npgsql can behave better inside DataSet and DataRow objects as they use Value property and expect CLR types being returned.

What is the problem and what can I do about it?

The problem lies in the fact that now, NpgsqlParameter.Value returns only CLR types. So, if your code was expecting to receive Npgsql specific types you may need to change your code to either use CLR type or change the call to NpgsqlValue property.

I think the first option is a good one as it will make your code more portable between other providers. If you are using only Npgsql, second option is a better choice as it will allow you to use directly Npgsql specific types.

We would like to hear from you how this modification is working for you.
Please, post your questions and suggestions in our user forums.

Thanks in advance.
Labels:

Comments

Post a Comment

Popular posts from this blog

Npgsql Design time support preview available for download!

UPDATE2 : For some reason, Blogger lost the original post. I had to republish it. UPDATE : Jerónimo told me that you  must  use the Npgsql version which is inside the zip file in order to make it work. After so much time (more than I wanted it to take) Npgsql finally has a initial design time support for Visual Studio! This work was done by Jerónimo Milea. Jerónimo let me know he was working on DDEX support on this thread  after I said I was working on DDEX support for Npgsql. He sent me his working copy and I started to play with it. Note that as a preview version many things may not work ok and we wanted you to provide us feedback so we can fix any bugs. You can download the project file from our downloads page . Design time support is provided as a zip file containing support code as well as a copy of Npgsql project file. So, everything you need to start working with design time support is already packaged for you. When you unzip the file, you will have ...
42 comments
Read more

Npgsql Tips: Using " in (...)" queries with parameters list and "any" operator

Hi, all! We have received some users questions about how to send a list of values to be used in queries using the "in" operator. Something like: select foo, bar from table where foo in (blah1, blah2, blah3); Npgsql supports array-like parameter values and the first idea to have this working would try to use it directly: NpgsqlCommand command = new NpgsqlCommand("select * from tablee where field_serial in (:parameterlist)", conn); ArrayList l = new ArrayList(); l.Add(5); l.Add(6); command.Parameters.Add(new NpgsqlParameter("parameterlist", NpgsqlDbType.Array | NpgsqlDbType.Integer)); command.Parameters[0].Value = l.ToArray(); NpgsqlDataReader dr = command.ExecuteReader(); but unfortunately this won't work as expected. Npgsql will send a query like this: select * from tablee where field_serial in ((array[5,6])::int4[]) And Postgresql will complain with the followin...
45 comments
Read more

Initial EF-6 support added to Npgsql

In my last post , I said there is a pull request by Pēteris Ņikiforovs to add support for EF-6 to Npgsql. Yesterday, I merged this pull request to the master branch of Npgsql . With this merge, Npgsql has officially initial support for EF-6! How to compile For now, in order to compile Npgsql to use EF-6, you have to open the solution file NpgsqlEF6.sln. Later,  as suggested by Pēteris Ņikiforovs , the idea is that we create a new configuration inside main project solution instead of maintain 2 separated projects. Another thing you will need to compile Npgsql is the latest release of EntityFramework assembly through NuGet: PM> Install-Package EntityFramework -Pre That's it! Now you will be able to play with Npgsql and EF-6. Check out my previous post about how to use Npgsql with EntityFramework. I'd like to thank Pēteris Ņikiforovs for his patch. And maxbundchen for his patch about Open/Close events needed for EF-6. Please, give it a try and let me know ...
44 comments
Read more