Francisco Figueiredo Jr Activities

      Happy 20th Anniversary, Npgsql!      It seems like yesterday when I decided to start Npgsql. And today, Npgsql completes 20 years since the first public beta release!     On May 18th, 2002, this is what was written in the first release notes of Npgsql  version 0.1:   2002-05-18          First Npgsql beta release.     In this version there is a limited functionality. It is only possible to connect and disconnect from server.     Only clear text authentication is supported right now.     To compile you can use the SharpDevelop to open the Combine file (Npgsql.cmbx) or type at command console: csc /t:library /out:Npgsql.dll NpgsqlConnection.cs AssemblyInfo.cs NpgsqlException.cs This will create the file Npgsql.dll that can be copied to the application directory.     I will be working in the Command functionality now.     ...

This is Npgsql 2.2.0 Final Release This release contains 249 commits since the last stable release. Includes bug fixes, improvements and new features. Update notice: If you have been using Npgsql 2.2.0-rc2, you don't need to update to this version. They are the same except for the Assembly version information. Major highlights Visual Studio DDEX support   Kenji Uno added support for DDEX. Now you can use Npgsql with Visual Studio data designer. This is a missing feature a lot of our users requested in the past. Kenji added a tutorial about how to use Npgsql with DDEX. You can find it here: https://github.com/npgsql/Npgsql/wiki/Visual-Studio-Design-Time-Support---DDEX-Provider#install-npgsqlddexprovidervsix   Entity Framework   David Karlaš added support for EFMigration and Database creation in EF6+. Now it is possible to start Code First projects without needing to create a database upfront. EntityFramework and Npgsql will take care of it. E...

This release contains 22 commits since the last release. It contains the following bug fixes: [ #217 ] Impossible to insert a Double.NaN value [ #179 ] NpgsqlCommandBuilder automatic sql commands configuration [ #158 ] NpgsqlCommand.Dispose() should execute "DEALLOCATE " for a prepared command [ #264 ] Mono.Security is outdated [ #296 ] parameter parsing fails (regression) and duplicate [ #240 ] NpgSqlCommand does not substitute parameters when there is a string with escaped apostrophe A complete list of commits for this release can be found here: v2.2.0-beta1...release-2.2.0

The Npgsql Development team is proud to announce that Npgsql 2.2.0 beta1 is now available! This release has the following highlights: Visual Studio DDEX support Kenji Uno added support for DDEX. Now you can use Npgsql with Visual Studio data designer. This is a missing feature a lot of our users requested in the past. Kenji added a tutorial about how to use Npgsql with DDEX. You can find it here . Support for EFMigration and Database creation in EF6+ David Karlaš added support for that. Now it is possible to start Code First projects without needing to create a database upfront. EntityFramework and Npgsql will take care of it. Emil Lenngren added support for a lot of missing features of EntityFramework. Check out this list containing fixes from David and Emil as well as others for EntityFramework. SSLStream support In this release, SSLStream is on by default. If you want to use Mono.Security, you will need to use the following line in your code: NpgsqlC...

Yesterday I merged a pull request which adds support to .Net SSLStream in Npgsql. When Npgsql development started, in 2002, there was no SSL support in .net 1.0 and 1.1. It was added later in .net 2.0 but the support to SSLStream was never added to Npgsql. This all changed a few weeks ago when  Dave G created a patch which adds support to .Net SSLStream in Npgsql. He also said that one of the motivations was the fact that the current SSL support was returning error when using client certificate authentication. (I'll post a tutorial about how to use client certificates later) There is a very old feature request  (like since 2005!) to somehow create a single Npgsql.dll which incorporates Mono.Security.dll assembly. This would easy the deployment of Npgsql and version control. This feature request generated a discussion about the removal of Mono.Security dependency and possible impact in current user code.  In order to get the lowest impact by this change...

After a long delay, Nuget packages for 2.0.13-beta1 are finally available! Since they are beta, you will need to use a command line parameter when installing this package. According to Nuget , you will need to use the following command: PM> Install-Package Npgsql -Pre Please, give it a try and let me know if it works ok. This package also fixes  the problem of police files compiled to .Net 2.0 framework only. This was giving problems when installing Npgsql on .net 4.0 runtimes. Thanks  Yusuke Fujiwara for fixing it.

Today we released the first beta of Npgsql 2.0.13!  This new beta release had a lot of bugs fixed and initial support for Entity Framework 6! More information about how to use Entity framework 6 with Npgsql can be found in  this post . Checkout the release notes for more information about the bugs fixed in this release. Download it from our  downloads section . Important notice about this release Unfortunately, I made a mistake when updating the assembly version for this release and it was created with a wrong value. I'm very sorry for that. This release should have been 2.0. 12 .91 and not 2.0. 13 .91 Next beta release will have the version value fixed. What are the implications?  The biggest problem is that this beta version will have a version number higher than the final 2.0.13 version while this beta version has 2.0.13.91. As it is a beta and it is not supposed to be deployed in production systems, we think this won't give pr...

Recently,  I applied a patch from  Kevin Pullin  which will improve the performance of programs using Npgsql. This patch reduces significantly the time to create new NpgsqlConnection objects. This particularly applies in scenarios where you are creating and disposing a lot of NpgsqlConnection objects, like when  you are using connection pool , ( you are using it, right? :) ). Comparison test I made an artificial test to show the impact of this patch. This test consists of a simple loop where I create 10k NpgsqlConnection objects.  class   Program     {          static   void   Main ( string []  args )         {              var   connString   =   "server=127.0.0.1;userid=npgsql_tests;database=npgsql_tests;" ;        ...

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 ...

Since the beginning, in 2002, Npgsql has been using cvs as its source code management system (SCM). At the time, cvs was being used by a lot of opensource projects, and so it was a natural choice for Npgsql. A couple of days ago, Npgsql code moved to GitHub. I didn't blog about that in the same day because I wanted to make sure things went well before spreading the word. :) ( You may be asking yourself: But Npgsql code was already at GitHub, wasn't it? Yes, it was. But it was only a mirror of the main cvs repository. And I had to update the code manually every time. Every change had to go first to the main repository cvs and then I would update in GitHub. Obviously the code was often outdated. This is a thing of the past now.) Git was chosen mainly because there is a lot of documentation about it, it is powerful and because of GitHub. GitHub provides many resources which will help us have a much better environment for our collaborators and users. For our collaborat...

Sometimes, Npgsql users receive errors when working with connection pooling. The problem appears when they try to open a new connection and receive the following message:   "Timeout while getting a connection from pool." This is caused when an attempt is made to get a connection from a pool which  has all its connections used. Most of the time this problem is a difficult one to track because it generally happens when the system is in production and not in the development phase. Of course. :) Some time ago, I received a report from Miłosz Kubański about such a problem. I told him I would work in a way to get more information so we could check what was happening. In order to help us find the problem, I added a little  "hack" to  Npgsql: Whenever an error while getting a connection from the pool occurs, Npgsql would log a stacktrace of the allocation of all the connections which were in the pool. Theoretically, those connections which were allo...

You may already know that VS.Net design time support has started a long time ago  and didn't have too much support since then.  Now that Npgsql release 2.0.12  is out, I want to put more attention to finish a version which adds design time support. I noticed that this is the biggest missing feature in Npgsql and I want to fix that. Npgsql users deserve to be able to use VS.Net design time support to help them create better apps which access Postgresql databases. Although I can't give any concrete timeframe of when it will be available, I want you to know that I'm focused on this feature and it is not stalled. I hope to be able to give you more information soon. Stay tuned.

Hello, all! Npgsql2 source code hosted on pgfoundry  is now mirrored on github:  https://github.com/franciscojunior/Npgsql2 What does this mean to developers and users? You have another way of access to latest Npgsql2 code through github interface I hope it will be easier to developers and users to provide patches. You can make forks and pull requests. Please, if you weren't being able to access Npgsql2 source code because of cvs, please give it a try on this new interface and let me know if you have any problems. Thanks github for providing this service to open source community. 

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 ...

As I've said in my last post ,  Npgsql 2.0.11 is finally here! This release fixes the problem with bytea handling with Postgresql 9.0. This patch should have been applied a long time ago. My fault for not being there yet. Also on this release, Josh Cooley fixed some other bugs related to EF. Checkout the release notes here  for more info and download it from here .

Hi all! I'm aware of this problem and it is already fixed. We will be doing a new release on the next few days. For while, the current workaround is to fallback to previous handling style by changing postgresql.conf file. More info can be found here . Sorry for the problems this may have caused.

Hi all! It all started when Josh Cooley told me about this post:  http://devlicio.us/blogs/tuna_toksoz/archive/2010/07/27/codebetter-devlicio-us-msdn-ultimate-giveaways.aspx I sent a mail talking about Npgsql and how a VS.Net would help us to add design time support and today I received a very nice mail saying that Npgsql was choosen to receive an MSDN subscription! I'd like to thank the people who contributed to make this possible: Codebetter Crew : Ben Hall , Ward Bell , James Kovacs . Devlicious Crew : Hadi Hariri , Christopher Bennage , Tim Barcz , Rob Reynolds .  Lostechies Crew : Eric Hexter , Jimmy Bogard , Keith Dahlby and Josh Cooley for heads up! Thank you very much! Your support to OSS projects is awesome! And stay tuned for better support of Npgsql inside VS.Net :)

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 ...

Hi all! From time to time, we receive some questions regarding connection pool in Npgsql and I think I should post some info about its current design. Npgsql connection pool implements the common pattern of having some connections open beforehand so when one is needed, it will be readily available for using. How it works When a application opens a connection, Npgsql tries to find a pool of connections based on the connection string. If a pool doesn't exist, it is created with a number of connections specified in the MinPoolSize connectionstring parameter. After that, a connection is retrieved from this pool. The min and max number of connections created in each pool is controlled by connection string parameters called MinPoolSize and MaxPoolSize respectively. This way, users can fine tune the pool behavior to match their scalability needs. Npgsql controls the lifetime of unused connections in the pool, trying to get connections number near the minimum value set by user. This is d...

On my last post about that subject , I wrote about some optimizations I did to get better performance when calling functions with Npgsql. While that optimizations were very nice, they had a drawback: you had to reuse your NpgsqlCommand object. You had to reuse it because the optimizations were based on cached data and if you created a new NpgsqlCommand object the data would need to be cached again. In the general case, where you would create many NpgsqlCommand objects and call functions with them, you would not benefit from those optimizations. In order to fix that, Noah Misch created a patch which remove 2 of the 3 internal calls which were giving performance problems. The only case left is for functions which have return type of 'record'. We are working to get this case also covered. I'm going to show here how much performance improvement you get with this patch with a simple call to a function which returns an integer. This function is on Npgsql unit test suite, but I ...