Skip to main content

Posts

Showing posts from 2009

Better data type handling mechanism landed on cvs

Hi all! Yesterday, 2009-12-12, Josh Cooley committed a better datatype handling mechanism to Npgsql. This will allow Npgsql to be more consistent when handling types because it is now much better defined when to return specific (or provider specific) datatypes and when to return CLR datatypes. What does all this mean? Well, Npgsql now implements the methods DbDataReader.GetProviderSpecificValue() , DbDataReader.GetproviderSpecificValues() and GetProviderSpecificDataType() . With those methods implemented, users will have a defined way of getting the specific types provided by Npgsql. The other methods will now always return the CLR types. This modification will also enable Npgsql to work better with the ado.net library. For example, we have reports that NpgsqlInet data wasn't being rendered in a DataGrid . By inspecting the test case, the dataset was correctly filled, but Datagrid seemed to not like NpgsqlInet and didn't render its value. With this type handling modification...

Blogging from mobile

Hi all! I just installed an app which allows me to post direclty from my mobile. Now I think I'll be able to write more frequently, or at least I hope so. :-) Stay tuned! - Posted using BlogPress from my iPhone

Npgsql 2.0.7 released!

Hi all, Npgsql 2.0.7 is out. This is a minor bug fix release. The most notorious bug fix is one made by Josh Cooley about possible freezes and strange exceptions when canceling a query. So, if you were having any problem like this, please give it a try. Download it from: downloads.npgsql.org This is the release notes of this release: Bugs fixed: [#1010527] Fix query timeout connection corruption. [#1010700] Capture parameter names with NpgsqlCommandBuilder.DeriveParameters. Thanks Brian Schloz (bschloz @nospam@ hotmail.com) for patch. Also added nunit testcase. [#1010668] Npgsql ConnectionStringBuilder provides no connectionstring properties. Now Npgsql correctly reports default connectionstring properties. Thanks Alaric Dailey for heads up and patch! Fixed bug when trying to retrieve a date value with -infinity value. See more here: http://pgfoundry.org/forum/message.php?msg_id=1005249 Thanks Andrus Moor for bug report and test case and Laurenz Albe for repo...

Another postcard has arrived!

Hi, all! Another postcard has arrived. It is from Transylvania: It is from Alin Hanghiuc (Update: Thanks for correction, Alin!) from Brasov, Romenia. Thank you very much, Alin for sending this postcard. This give us a lot of motivation!

ASP.Net SQL Provider has a build server

Hi all! Daniel Nauck, the developer of ASP.Net SQL Provider for Postgresql , let me know today that he has setup a build server for his project. This means that users will be able to get the latest build easily. In order to download the latest build, point your browser to: http://build.nauck-it.de . Nice job, Daniel!!

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

Npgsql 2.0.5 released!

Hi, all! Npgsql Development Team released Npgsql 2.0.5. This is a bug fix release. And we fixed some important bugs. The first one is about the famous NotSupportedException seek operation. Npgsql now handles this by flushing the stream before writing to it. It is not the complete solution but it is an step in the right direction. Another bug which is open for quite some time is the return value of DataAdapter.Update. It wasn't working very well for multiple statements. Now it is working ok. Josh Cooley added a lot of fixes for Entity Framework and Transactions support. Please, check our release notes to see all the changes on this release. You can download this release on our usual location . Thanks everybody who helped us with comments, feedback and patches.

First Postcard arrived!!

Hi, all! A few days ago I checked my mail box and noticed that there was a postcard there! It is from Albe Laurenz. The postcard is from Vienna, Austria. Here it is: Thank you very much for your postcard, Albe. It is very nice! I loved it.

Last activities about Npgsql....

Hi all! It's been a long time since my last post. I've been a little bit busy those days (or it's better say: months!) but I'm catching up with Npgsql bugs little by little. Today I fixed a bug which was making Npgsql to not return the correct number of rows affected by an update when using DataAdapter.Update() method. This bug was floating around for a long time! Thanks Christian for the heads up and testcase! Some weeks ago, I played with another bug which was causing the famous "stream doesn't support seek operations" exception. It turned out that that the large object api isn't handling errors correctly which is letting data on the stream which causes the problem. I have an ugly workaround for this which is simply flush the stream before trying to write to it again. I sent a message to Npgsql dev list explaining this issue with more details. That's it for while. I'll be hunting down the remaining bugs and will post progress here.

Playing with Firefox 3.1beta2

Well, after a long time playing with nightly Webkit because Firefox wasn't so good on my mac, I decided to give it a try again with 3.1 beta2 and.... Wow! It's amazing! Super fast and I can even say that it seems faster than last webkit builds. I also liked that it seems to use a little less cpu than webkit which is very nice! Kudos to Mozilla Firefox people who is doing an excellent job regarding performance of firefox on OSX and from what I saw on other OS's too.