YiiFirebird 1.0 is marked as stable we need more volunteers for writing and doing tests

It seems that now the YiiFirebird extension is stable enough (please let me know it is not so) for merge in YiiFramework master repo.
Now, the next step is to create the automated tests for this extension. Volunteers? Ideas?
We need to add a “tests” directory for that purpose in our local repo before committing Yii master repo.
Example: https://github.com/yiisoft/yii/blob/master/tests/framework/db/schema/CPostgresTest.php

Comment on this issue

 

Custom conventions in Entity Framework 6 helping Firebird – part 2

Few days ago I wrote a post “Custom conventions in Entity Framework 6 helping Firebird“.Arthur Vickers from Entity Framework team had a good question whether it works also for columns and tables that are generated by Entity Framework (like join tables for M:N, FK columns (if not in model), etc.). And it actually does not. :) For this you have to dig a little bit deeper and use model-based convention.

New implementation for wire protocol in Jaybird and all drivers need a faster wire protocol

Mark Rotteveel wrote on twitter about the Jaybird improvement:

Writing a new implementation of the wire protocol in Jaybird. I fear it is going to cascade into a total rewrite of the driver

Jiri chatted later:

IMO the whole “communication layer” needs redesign. It’s (way) too legacy.

And later on the twitter channel Brent Rowland wrote:

Contemplating creating a new wire protocol. Stop me now…
I have a replication system for Firebird I need to extend across a WAN. Firebird has no built-in replication and the protocol is chatty.

Editor:All these conversations are around Firebird 2.5.x protocol , there is work conducted by Dmitry Yemanov on improving the Firebird 3.x protocol

Jaybird 2.2.2 Released

The Firebird JDBC team is happy to announce the release of Jaybird 2.2.2.

See http://www.firebirdsql.org/en/jdbc-driver/ for the downloadlinks.

The release is also available on maven:
<groupId>org.firebirdsql.jdbc</groupId>
<artifactId>jaybird-jdkXX</artifactId>
<version>2.2.2</version>

The artifactId depends on your target Java version: jaybird-jdk15,
jaybird-jdk16 or jaybird-jdk17

The following has been changed or fixed in Jaybird 2.2.2:

  • Fixed: FBMaintenanceManager.listLimboTransactions() reports incorrect transaction id when the result contains multi-site transactions in limbo (JDBC-266)
  • Fixed: Calling PreparedStatement.setClob(int, Clob) with a non-Firebird Clob (eg like Hibernate does) or calling PreparedStatement.setClob(int, Reader) throws FBSQLException: “You can’t start before the beginning of the blob” (JDBC-281)
  • Fixed: Connection property types not properly processed from isc_dpb_types.properties (JDBC-284)
  • Fixed: JNI implementation of parameter buffer writes incorrect integers (JDBC-285, JDBC-286)
  • Changed: Throw SQLException when calling execute, executeQuery, executeUpdate and addBatch methods accepting a query string on a PreparedStatement or CallableStatement as required by JDBC 4.0 (JDBC-288)
    NOTE: Be aware that this change can break existing code if you depended on the old, non-standard behavior! With addBatch(String) the old behavior lead to a memory leak and unexpected results.
  • Fixed: LIKE escape character JDBC escape ({escape ‘<char>’}) doesn’t work (JDBC-290)
  • Added: Support for a connect timeout using connection property connectTimeout. This property can be specified in the JDBC URL or Properties object or on the DataSource. If the connectTimeout property is not specified, the general DriverManager property loginTimeout is used. The value is the timeout in seconds. (JDBC-295)
    For the Java wire protocol the connect timeout will detect unreachable hosts. In the JNI implementation (native protocol) the connect timeout works as the DPB item isc_dpb_connect_timeout which only works after connecting to the server for the op_accept phase of the protocol. This means that – for the native protocol – the connect timeout will not detect unreachable hosts within the timeout. As that might be unexpected, an SQLWarning is added to the connection if the property is specified with the native protocol.
  • As part of the connect timeout change, hostname handling (if the hostname is an IP-address) in the Java wire protocol was changed. This should not have an impact in recent Java versions, but on older Java versions (Java 5 up to update 5) this might result in a delay in connecting using an IP-address, if that address can’t be reverse-resolved to a hostname. Workaround is to add an entry for that IP-address to the /etc/hosts or %WINDIR%\System32\Drivers\etc\hosts file.
1 10 11 12 13 14 78