The Mysql2 gem is meant to serve the extremely common use-case of
connecting, querying and iterating on results. Some database libraries
out there serve as direct 1:1 mappings of the already complex C APIs
available. This one is not.
Swift is a fast database API and ORM for ruby 1.9, featuring:
* Multiple databases.
* Prepared statements.
* Bind values.
* Transactions and named save points.
* EventMachine asynchronous interface.
* IdentityMap.
* Migrations.
dbic++ is a database client library written in C++ which comes with
support for PostgreSQL and MySQL. It's main features are:
* Simple API to maximize cross database support.
* Supports nested transactions.
* Auto reconnect, re-prepare & execute statements again unless inside
a transaction.
* Provides APIs for async queries and a simple reactor API built on
libevent.
other data_mapper gems.
DataMapper is a Object Relational Mapper written in Ruby. The goal is to
create an ORM which is fast, thread-safe and feature rich.
ok landry
DataMapper Plugin that adds foreign key constraints to associations.
Currently supports only PostgreSQL and MySQL. All constraints are added
to the underlying database, but constraining is implemented in pure
ruby.
ok landry
Arel is a Relational Algebra for Ruby. It 1) simplifies the generation
complex of SQL queries and it 2) adapts to various RDBMS systems. It is
intended to be a framework framework; that is, you can build your own
ORM with it, focusing on innovative object and collection modeling as
opposed to database compatibility and query generation.
ok landry
Previously, we were using ruby->=1.8,<=1.9, instead of
ruby->=1.8,<1.9. While this wouldn't cause an issue, since
our ruby-1.9.2 package isn't included in ruby->=1.8,<=1.9,
it's still wrong and should be fixed. This also fixes the
following minor issues:
Switch from using FLAVOR to MODRUBY_FLAVOR for *_DEPENDS.
Currently we don't have a ruby port that uses FLAVORs that
would differ from MODRUBY_FLAVOR, but it's possible we will
in the future.
Switch from BASE_PKGPATH to BUILD_PKGPATH in a few cases in
REGRESS_DEPENDS. This probably is not strictly necessary, but
BUILD_PKGPATH is used in more cases, so it is good for
consistency.
Switch to new style *_DEPENDS, with the version specification
at the end. The remaining cases where this is not done is
because a specific version is used.
Some FULLPKGNAME added to REGRESS_DEPENDS, to make sure that if
the old version is installed when you run a regress test, it
will install the new version first.
Some conversion of spaces to tabs for consistency.
OK landry@
