Embedded InnoDB New Database Engine

Oracle has released Embedded InnoDB.

Most recently, the "red giant" released Embedded InnoDB , under a fairly democratic GPLv2 license, not Apache 2.0 but also bearable.
Currently this database is available only for 32-bit versions of Windows and Linux.
I would not venture to download and install, first I want to look around. Go to the dock and read. Since today at work I don’t have to do anything anyway I’ll do a little review-translation.

The text from the docks will be written in italics below, in normal type my opinion on this matter.

Concept.

This database is designed for critical applications and successfully handles both kilobytes of data and volumes of several gigabytes.
For access to data and management of a DB and transactions special API are used.
It is like no Tib SQL, yet not so entertaining.
Since InnoDB is an embedded engine, it is super fast.
Now I want to test this, perhaps by the end of the article they will promote me to install InnoDB and test it.
The reason for the speed of this database is that it runs in the same address space as your application, and allows you to avoid costly communication procedures as in the case of classical DBMS.
Hmm, something like Google Gears ??
The important point is that this DBMS is not a relational database and as a result does not provide such high-level functions as triggers and nothing like SQL. InnoDB is just a set of low-level APIs for efficiently reading / writing your data.
Embedded InnoDB allows you to embed a database processor into your application, without having to install any other DBMS you have. Database operations are carried out by means of the plugin. Which allows you to perform standard actions: insert, update, delete with ordinary relational tables and columns, as well as allows you to manage transactions and return data cursors.

This DBMS allows:

• Work with columns and indexes.
  
  
• Your calls are not made using SQL, you operate with API calls.
  
  
• Your application can be without installer. All libraries are linked both dynamically and statically. All parameters have default values. All necessary files will be created. At the moment there is no need to affix any system variables.
• Working with the database is performed by ACID transactions (Atomicity, Consistency, Isolation, Durability) and supports commit / rollback / savepoint operations.
  
• The application returns data in the form of a classic cursor.
  
  
• You can control the isolation levels of a transaction, and the same lock model for both tables and cursors.
  
  
• Can know foreign keys.
  
  
• It does not allow changing the column properties after creating the table.
  
  
• Able to B-tree data structures.
  
  

')

Using.

Download set, old bd, run any IDE.
create a database:
ib_err_t err = ib_database_create("test");
create a label:
plain
CREATE TABLE T(c1 VARCHAR(32), c2 VARCHAR(32), c3 UNSIGNED INT, PK(c1, c2));
in the API language InnoDB will look like this:
ib_trx_t ib_trx;
ib_id_t table_id = 0;
ib_tbl_sch_t ib_tbl_sch = NULL;
ib_idx_sch_t ib_idx_sch = NULL;
char table_name[IB_MAX_TABLE_NAME_LEN];

snprintf(table_name, sizeof(table_name), "%s/%s", database_name, name);

/* Pass a table page size of 0, ie., use default page size. */
ib_table_schema_create(table_name, &ib_tbl_sch, IB_TBL_COMPACT, 0);

ib_table_schema_add_col(ib_tbl_sch, "c1", IB_VARCHAR, IB_COL_NONE, 32);
ib_table_schema_add_col(ib_tbl_sch, "c2", IB_VARCHAR, IB_COL_NONE, 32);
ib_table_schema_add_col(ib_tbl_sch, "c3", IB_INT, IB_COL_UNSIGNED, 4);

/* Index schema handle is "owned" by the table schema handle in this
case and will be deleted when the table schema handle is deleted. */
ib_table_schema_add_index(ib_tbl_sch, "PRIMARY_KEY", &ib_idx_sch);

/* Set prefix length to 0. */
ib_index_schema_add_col( ib_idx_sch, "c1", 0);

/* Set prefix length to 0. */
ib_index_schema_add_col( ib_idx_sch, "c2", 0);

ib_index_schema_set_clustered(ib_idx_sch);

/* Create the transaction that will cover data dictionary update. */
ib_trx = ib_trx_begin(IB_TRX_SERIALIZABLE);

/* Lock the data dictionary in exclusive mode */
ib_schema_lock_exclusive(ib_trx);

/* Create the actual table from the schema. The table id of the new
table will be returned in table_id. */
ib_table_create(ib_tbl_sch, &table_id);

/* Commit the transaction */
ib_trx_commit(ib_trx);

/* Release the data dictionary lock. */
ib_schema_unlock(ib_trx);

ib_table_schema_delete(ib_tbl_sch);

The scope of this database is primarily autonomously operating devices that, by definition, have no connection with the outside world, but are entrusted with the functions of collecting some data. It is also possible to use on mobile devices, given that the application with open source it should be perfectly installed in the android.
So it begs the comparison with Google Gears, very similar technologies. The difference Gears for browser-based offline applications applications, InnoDB for desktop.
However, Google has better implemented it in terms of user friendliness, Google is able to complete SQL.
The code similar to the predecessor on Google will look like this:

try {
db = Factory.getInstance().createDatabase();
db.open("BaseApp11");
db.execute("create table if not exists baseapp11 (Timestamp int)");
db.execute("delete from baseapp11");
} catch (GearsException e) {
Window.alert(e.toString());
}
At least 100 times more concise is it not ?? But despite all the convenience, Google cannot boast of ACID transactions, built-in database recovery tools, or B-tree indexes.