[Catalyst] DBIC/RDBO comparison (excuse new thread)

[Matt S Trout]

Damn it, I've lost which message I should be replying to.

But to answer the freshness question -

UNIQUE RDBO FEATURES

* Support for Informix.

-- no idea, we may have users, we may not :)

* Objects may be loaded based on unique keys.

-- DBIC has this

* Extensive column metadata: data types, size limits, default values.

-- DBIC can take this info but lets the DB enforce it

* Bundled set of column classes for most commonly used data types,
with integrated inflate/deflate, validation, and other convenience
functions.

-- not exactly but things like InflateColumn::DateTime provide it as an add-on

* The bundled column classes also support some esoteric column types:
Informix SET columns, Postgres CHKPASS, BIT, and array columns.
(Inflate/deflate is done to/from Perl arrays and Bit::Vector objects
as appropriate; Postgres arrays and bitfields are emulated in other
databases.)

-- nope. nobody's ever asked for this except for pg arrays, which I'm waiting
for somebody to care about enough to write tests :)

* In addition to inflate/deflate, column triggers can also be applied
to get/set (user data) and load/save (to/from database) events.

-- DBIC has always allowed this via subclassing, triggers are just a
performance hit you don't need.

* Can auto-join via one-to-many and many-to-many relationships,
fetching all data in a single query, preserving custom sort orders
for sub-objects.

-- DBIC implemented this in 06, pretty much

* Queries accept "rich" values as arguments (e.g., DateTime and
Bit::Vector objects)

-- expected in 09

* Bulk update and delete methods, which also work with "rich" query
arguments.

-- resultset objects provide this

* By default, when an object's related sub-objects are added or
updated through that object, all changes are delayed until the
"parent" object is saved, at which time all outstanding changes occur
within a single transaction. ("Immediate" actions are also supported.)

-- 08 will support this for create, anything else you use txn_do for

* Support for "SELECT DISTINCT ..." queries.

-- distinct => 1

* Lazy loading can be overridden on a per-class basis during single
and multi-table queries.

-- no, but the select/as mechanism has proven sufficient so far

* Database migration: copying objects from one database to another by
trading "db" (Rose::DB) objects. Works across database types (e.g.,
Postgres to MySQL) provided that all column data types exist (or are
emulated) in both places.

-- largely works. dunno how far users have stressed this.

* In addition to extracting column names, primary keys, and foreign
keys, the RDBO loader can also do the following:

- Configure column data types, size limits, and default values.
- Extract and configure unique keys.
- Set up all relationship types, including many-to-many relationships.

-- Schema::Loader basically handles this

* All automatic behavior and naming conventions are encapsulated in a
"convention manager" object. Using different convention managers
will alter the behavior of the loader and other automatic processes.
(e.g., A "Rails" convention manager could enforce the Ruby on Rails
naming conventions for classes and tables.) 

-- no, but everything is configurable pretty much

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/             http://www.shadowcatsystems.co.uk/