I am looking for an open source free to distribute JDBC driver for Cassandra. I have worked with Simba JDBC driver but this isn't freely distributable. Is there any recommendation on a popular open source driver?
Unfortunately, I am not aware of any open-source JDBC driver for Cassandra in existence.
The JDBC driver from Magnitude (formerly Simba) is paid for by DataStax and DataStax then distributes it to users at no cost.
Maintaining drivers is quite expensive so there are hardly any groups willing to invest resources in it. There are very few exceptions like the authors of GoCQL.
Full disclosure: I work at DataStax so I have an insight on it. Cheers!
To connect to the AWS Redshift we can use JDBC or ODBC drivers. Recently I have heard that the JDBC drivers performance is about 40% better than ODBC ones. Unfortunately, I cannot find such information somewhere in the documentation.
Do you have any experiences which drivers perform better on AWS Redshift?
There may be minor differences in query execution time for different driver types due to the following:
https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html#compiled-code
The execution engine compiles different code for the JDBC connection protocol and for ODBC and psql (libq) connection protocols, so two clients using different protocols will each incur the first-time cost of compiling the code. Other clients that use the same protocol, however, will benefit from sharing the cached code.
Note that first time compilation cost has been dramatically reduced in recent Redshift releases.
I have an idea to write an application to work with SAP Sybase IQ16 server using Go language. Platform windows/nix does not matter yet. I had workewd with this database using C# later, and I remember, that there was no ADO.NET driver, so I used ODBC + iAnywhere.Data.SQLAnywhere.v4.0.dll to establish connection. Also, I know, that drivers for IQ, ASE, etc... are not compatible. I looked here https://github.com/golang/go/wiki/SQLDrivers, but neither оf drivers seems to be compatible. Thus, I can not understand at all is there solution for my problem.
can anyone tell me How does jdbc work? How it manages to communicate with a DBMS? since DBMS may be written with some other programming language.
Communication with the database is handled by JDBC drivers that can use various strategies to "talk" to a database (from "translation" to the use of "native" language). Depending on the strategy used, drivers are categorized into 4 types. Types of JDBC technology drivers provide a good description of each of them:
A JDBC-ODBC bridge provides JDBC API access via one or more ODBC
drivers. Note that some ODBC native
code and in many cases native database
client code must be loaded on each
client machine that uses this type of
driver. Hence, this kind of driver is
generally most appropriate when
automatic installation and downloading
of a Java technology application is
not important. For information on the
JDBC-ODBC bridge driver provided by
Sun, see JDBC-ODBC Bridge Driver.
A native-API partly Java technology-enabled driver converts
JDBC calls into calls on the client
API for Oracle, Sybase, Informix, DB2,
or other DBMS. Note that, like the
bridge driver, this style of driver
requires that some binary code be
loaded on each client machine.
A net-protocol fully Java technology-enabled driver translates
JDBC API calls into a DBMS-independent
net protocol which is then translated
to a DBMS protocol by a server. This
net server middleware is able to
connect all of its Java
technology-based clients to many
different databases. The specific
protocol used depends on the vendor.
In general, this is the most flexible
JDBC API alternative. It is likely
that all vendors of this solution will
provide products suitable for Intranet
use. In order for these products to
also support Internet access they must
handle the additional requirements for
security, access through firewalls,
etc., that the Web imposes. Several
vendors are adding JDBC
technology-based drivers to their
existing database middleware products.
A native-protocol fully Java technology-enabled driver converts
JDBC technology calls into the network
protocol used by DBMSs directly. This
allows a direct call from the client
machine to the DBMS server and is a
practical solution for Intranet
access. Since many of these protocols
are proprietary the database vendors
themselves will be the primary source
for this style of driver. Several
database vendors have these in
progress.
As we can see, there are various strategies to make interoperability possible, including implementing the network protocol used by a given database in Java (type 4). And because of their ease of use (no extra stuff to install, no JNI) and their good performances (they perform as well as type 2 drivers now), type 4 are actually the most frequently used nowadays.
From Wikipedia:
JDBC drivers are client-side adapters (installed on the client
machine, not on the server) that convert requests from Java programs
to a protocol that the DBMS can understand. [edit] Types
There are commercial and free drivers available for most relational
database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Most database systems support ODBC (Open Database Connectivity or whatever). This is meant to allow applications (e.g., Access) to work with multiple RDBMS implementations at the cost of some performance hit. When JDBC was first released, there was a driver that allowed you to connect to an ODBC provider. Later on, some vendors provided JDBC drivers specific to their RDMS.
From a developer's perspective, JDBC is used as a set of interfaces. All the actual details are hidden in loading the driver. The driver is a Java class that can use any trick of the book, including native code or just sending network traffic to the RDBMS.
From Wikipedia:
JDBC is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.
JDBC was first introduced in the Java 2 Platform, Standard Edition, version 1.1 (J2SE), together with a reference implementation JDBC-to-ODBC bridge, enabling connections to any ODBC-accessible data source in the JVM host environment.
Without going into too much detail, you can think of JDBC as an abstraction layer that lets you talk to different databases. The implementation-specific details are hidden from you, but the interface for querying a database (be it MySQL or Oracle or whatever) is the same.
What this means is that in future, if there was a new database, someone only needs to use the existing interface. The method names would be the same, but the methods would contain implementation-specific code for that particular database. This is a common software-engineering pattern.
The entity that contains the implementation-specific code is called the JDBC driver. The JDBC driver provides a connection to the database and it also implements the specific protocol for sending the query to the database and the result-set back to the client.
Can't say I know the exact answer to your question, but here is some information to help.
Here's a great place to start:
http://java.sun.com/products/jdbc/overview.html
The JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is the lower-level JDBC driver API for driver writers.
Information for JDBC Driver Developers. Basically there are a set of interfaces that a developer implements to create a JDBC driver for a particular DBMS.
http://java.sun.com/products/jdbc/driverdevs.html
As far as a DBMS being written in a different language. That DBMS most likely exposes some API (in various languages and/or formats) that allow for drivers, such as JDBC, to communicate with the DBMS.
From the wikipedia page:
Types
There are commercial and free drivers available for most relational database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Reading a bit about the four types of JDBC drivers might enlighten you.
i am looking for an Delphi component to connect to an ORACLE database server in an direct way without install the oracle client.
i knew the Oracle Data Access (ODAC) from DevArt. there are any other component with this capability?
ODAC offers two connection modes to
the Oracle server: connection through
the Oracle Call Interface in Client
mode and direct connection over TCP/IP
in Direct mode. ODAC-based database
applications are easy to deploy, do
not require installation of other data
provider layers.
Thanks in advance.
No, there is no other Delphi Win32 libraries allowing to connect to Oracle without the installed Oracle Client. And, IMHO, that is correct, because:
OCI (Oracle Call Interface) is quite complex piece of software. I will say, it is most complex closed sourced DBMS Call Level Interface in the World. And it is changing from version to version. Oracle has official rule - the Oracle Client v X supports Oracle Server v X-1 ... X+1. Because even such company as Oracle, dont want to spend resources to support and test all the protocol nuances across all possible versions. So, I dont think, that DevArt ever will implement 99.9% stable Oracle SQL*Net protocol implementation. And the INet posts proof that ...
AFAIK, the ODAC Net mode does not support some of the Oracle Client important features and has some important limitations. Although it works well for simple data access scenarious.
If you will purchase Oracle support, then it will decline all your support requests, if they will know, that you are not using official client software. That is just Oracle rule.
If you dislike to install and tune the full scale Oracle Client, then you can just use Oracle Instant Client. Which does not require install or setup procedure. And you will be in safety in case of the different data access scenarious and Oracle Server versions.
PS: Although I may be considered as a biased person :)
There is also Allround Automations Direct Oracle Access, it do require Oracle SQL*Net or Net8. but is a brilliant component suite.
The only solution I found is ODAC, and it's working very nice, I have been using it since years without getting any problem with the direct mode.
there's some limitation with the direct mode, but most of users will not get these limitations with their application.