Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native OO API implementations #19

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

vasiliy-yashkov
Copy link
Contributor

New OO API interfaces implementations and tests for them.
Classes are in a separate package org.firebirdsql.nativeoo.gds.ng by analogy with existing JNA implementations. Some batch interfaces (FbBatch, etc.) have been added to the wire layer and can be used for wire implementations. Connection through new interfaces is carried out through its own protocols: jdbc:firebirdsql:fboo: [embedded:|locale:|native:].
Interface FbInterface extends FbClientLibrary, while the library has only the definition of the interface IMaster.
FbInterface was generated by modified cloop.

New OO API interfaces implementations and tests for them.
Classes are in a separate package org.firebirdsql.nativeoo.gds.ng by analogy with existing JNA implementations. Some batch interfaces (FbBatch, etc.) have been added to the wire layer and can be used for wire implementations. Connection through new interfaces is carried out through its own protocols: jdbc:firebirdsql:fboo: [embedded:|locale:|native:].
Interface FbInterface extends FbClientLibrary, while the library has only the definition of the interface IMaster.
FbInterface was generated by modified cloop.
@mrotteveel
Copy link
Member

Thanks, as I mentioned on the mailing list, I'll try to review it this weekend.

@@ -35,14 +32,14 @@
public abstract class AbstractNativeDatabaseFactory implements FbDatabaseFactory {

@Override
public JnaDatabase connect(IConnectionProperties connectionProperties) throws SQLException {
public FbDatabase connect(IConnectionProperties connectionProperties) throws SQLException {
Copy link
Member

@mrotteveel mrotteveel Oct 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you remove the covariant inheritance here? This also introduces casts in TestJnaDatabase and TestJnaBlob (and other tests) that were previously unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot. It was a rough initial version, need to reverse it.

Copy link
Member

@mrotteveel mrotteveel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this should be a separate library entirely: both the fboo bindings, and this batch API.

My main concern is that I don't think the proposed batch API (and related interface/classes) belongs as part of the gds-ng API: it doesn't mesh well with the JDBC part of the driver and it will need significant changes to be usable from JDBC. It also deviates significantly from the normal metadata usage (field descriptor, etc) in gds-ng.

My secondary concern is the additional burden of taking on the maintenance of the OO API bindings as part of Jaybird. I hadn't realized earlier the amount of code involved.

*
* @since 4.0
*/
public class FbException extends SQLException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this exception really need to exist; the SQLException hierarchy is pretty complex, and this flattens it back to a single exception given the implementation in checkException

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll reconsider the importance of class. This class was created to satisfy Cloop requirements when generating interfaces. I have to change the definition of interfaces, maybe.


if (!builder.isEmpty()) {
SQLException exception = builder.toSQLException();
throw new FbException(exception.getMessage(), exception.getSQLState(), exception.getErrorCode(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This removes the subclasses that FbExceptionBuilder may generate depending on the error code and sql state, in addition it loses other exception information that the builder produces. That is not a desirable solution. If possible this class should be removed, and otherwise it should not extend SQLException and contain the SQLException as its cause.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I'll try to convert IStatus message to ISC_STATUS in order to use processStatusVector method to generate SQLException. Right?

* @since 4.0
*/
public interface BatchParameterBuffer extends ParameterBuffer {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove methods already defined in ParameterBuffer, or revise method documentation to be specific to batch parameter usage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ок.

@@ -35,14 +32,14 @@
public abstract class AbstractNativeDatabaseFactory implements FbDatabaseFactory {

@Override
public JnaDatabase connect(IConnectionProperties connectionProperties) throws SQLException {
public FbDatabase connect(IConnectionProperties connectionProperties) throws SQLException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, revert back to covariant inheritance

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

@@ -471,6 +471,21 @@ public void cancelEvent(EventHandle eventHandle) throws SQLException {
}
}

@Override
public FbBatch createBatch(FbTransaction transaction, String statement, FbMessageMetadata metadata, BatchParameterBuffer parameters) throws SQLException {
throw new SQLException("Not implemented");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use FBDriverNotCapableException (also for the other two methods)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree.

/**
* Register existing blob.
*/
void registerBlob(long existingBlob, long blobId) throws SQLException;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the meaning and difference between existingBlob and blobId?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

existingBlob has ID assigned by engine (when GDSHelper's createBlob method is called). blobId is user defined. registerBlob is used when BLOB_STREAM parameter is set as TAG_BLOB_POLICY.

/**
* Add blob in this batch.
*/
FbBlob addBlob(byte[] inBuffer, long blobId, BlobParameterBuffer buffer) throws SQLException;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can a caller decide on a blobId?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If TAG_BLOB_POLICY is set to BLOB_ID_ENGINE, then caller can not specify an blobId, otherwise, can specify existing blobId.

* @return Instance of {@link FbBatch}
* @throws SQLException
*/
FbBatch createBatch(FbTransaction transaction, String statement, FbMessageMetadata metadata, BatchParameterBuffer parameters) throws SQLException;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this belongs in FbDatabase, it should be part of FbStatement if anything.

However, in its current form, I don't think that these methods should be part of the gds-ng API. I see a lot of mismatches with the requirements for JDBC batch execution and the normal usage of the gds-ng API.

Making this part of the gds-ng API now, will only lead to a lot of rearchitecturing and breaking API changes later when I will try to make a uniform API that can be used from the JDBC part of the driver.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to think about it. Are there any templates of uniform interface?

@@ -434,7 +434,8 @@ private FbTransaction getTransaction(FbDatabase db) throws SQLException {
private static void safelyClose(FbDatabase db) {
if (db == null) return;
try {
db.close();
if (db.isAttached())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid 'is not attached to a database' message.


@ClassRule
public static final GdsTypeRule testType = GdsTypeRule.supports(EmbeddedGDSFactoryPlugin.EMBEDDED_TYPE_NAME);
public abstract class TestServicesAPI {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the changes to this class (and the creation of its subclasses) can be avoided by making proper use of the GdsTypeRule and FBTestProperties.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to do it.

1. Removed FbException handling class. Now, to form an exception, the status vector is processed after native methods calls and an SQLException is generated.
2. Exception handling works with the specified database encoding.
3. Methods that do not have batches implementations throw FBDriverNotCapableException instead of SQLException.
4. The batch generation mechanisms is similar to the implementation of prepared statements:
4.1. The batch generates field descriptors based on the prepared statement.
4.2 If the batch is created from external metadata, then it makes field descriptors like a prepared statement.
4.3 The batch uses methods to set the request fields like a prepared statement. The conversion of data of these fields in this case is carried out by FBField class, which uses database encoding and other parameters.
5. Changed test class names. Instead of TestXXX, to XXXTest.
6. Using GdsTypeRule for native tests.
7. Minor bugs fixed.
vasiliy-yashkov and others added 19 commits January 28, 2020 14:50
1. Updated interfaces `FbInterface.java` in accordance with the current firebird 4 implementation. Removed old and unnecessary interface implementations. `fb_get_master_interface()` method moved from FbClientLibrary to separate old and new implementations.
2. Fixed setting `null` flag ​​in message data of `IStatement` if the field data was `null`.
3. Removed excess imports of `org.firebirdsql.nativeoo.gds.ng.FbInterface` from `org.firebirdsql.gds` layer.
4. The batch parameter buffer now contains constants instead of the `FbBatch` interface.
5. Reimplemented event handling with old `isc_*` calls.
6. JNA deprecated function `loadLibrary` replaced by `load`.
7. Other corrections and additions related to main code of the driver.
… implementations

Additional changes:
1. Fix preparation of metadata when executing statement.
2. Add GDS type rule for new native support.
3. Replace SQL_DEC_FIXED with SQL_INT128.
4. Update gradle build config.
5. Add small comments.
1. Update interfaces for `fbclient` library.
2. Fix memory allocation for error message.
3. Fix parsing of warnings from status vector.
4. Fix `free` call when closing statement.
5. Update and fix tests.
Move implementation to `jaybird-native` dependency.
…h blobs in native batch

Also fix creation of `org.firebirdsql.jdbc.FBBlob` instances.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants