Ruby on Rails versus Oracle Objects (and object-oriented data persistence in general)

Question

I am new to Ruby as well as Rails but have been around a while with building front ends to Oracle. I am also new to object-oriented design (OOD) so I might have missed some important detail here as well. Anyhow, I have been given a chance to build a new product from the ground up with Ruby and Oracle (yes, it must be Oracle). Given the total OO nature of Ruby, I thought it made sense to try and build an OO data model as well (or, in the case of Oracle, an object-relational model). In my research into both Rails and Oracle Objects, however, instead of finding a solution, I found a disconcerting paradox. So, my basic question is: Am I missing something?

More Details

The basic problem I currently see is that Rails' ActiveRecord module is not compatible with Oracle Objects namely because it does not support complex data types such as Oracle's object type (or, if it does, I have yet to find documentation describing how). Therefore, ActiveRecord cannot easily work with Oracle tables that contain objects and/or collections of object references. In short, Rails wants to be database agnostic, Oracle Objects wants to be application agnostic, and these two philosophies are currently proving to be in conflict.

Example to Demonstrate the Point

What I would like to do is to use the same object definitions in both the app and the database to reduce or eliminate object-relational mapping. Because it appears, however, that Rails has no feature to create or read object types in Oracle, then it would not be worth the effort of creating an object-relational model in Oracle and to instead create a relational model. This, in turn, will have the side effect of greatly reducing the OO model in the Rails app. That is the paradox -- that the features of Rails inherently reduces it's own OOP capabilities by forcing relational data models for data persistence.

For example, suppose I have many widgets of various types. To support this in Oracle Objects, I might create a widget object type and various widget subtypes. I might then create a gadget object with an attribute that contains a collection of widget references to the various widget types and subtypes that make up the gadget. This object model sounds simple and elegant to me and should work well in Ruby as well. Throw Rails and ActiveRecord into the equation, however, and I suddenly find myself flatting the model into relational tables where I have a gadget table and a widget table (with a widget type column and various other columns to support the various widget types in one table) and a 1:N table between the two for attaching widgets to gadgets. Consequently, my objects in Rails will end up looking very similar to these tables with only one widget object type and no widget object subtypes (the widget object would simply have an attribute that indicates type). To try and instead build an object model in Rails that does not match the tables sounds like a future of query crime and punishment. This forced deviation from OOD feels tragic to me. Sure, another approach might be to try to fully normalize the tables and create various widget subtype tables, but this approach does not always make good sense in the relational world (due to lack of inheritance) and would cause major table-join headaches in my current project.

Putting Rails aside and focusing purely on Ruby, it does appear that the OCI8 interface is capable of working with Oracle object types. I have not found, however, any supporting documentation on how to use this. This makes it fairly apparent that the cost of dumping Rails to blaze my own trail here would be far too high (with the added cost that many find Oracle Objects itself to be clunky to use). Far simpler to use Rails with relational Oracle for a small project such as this.

When I try to imagine the complexities involved with trying to support object data types through ActiveRecord, or a similar module, it is understandable why this capability has not been built yet (particularly given the database-agnostic philosophy of Rails). Understandable... but unfortunate.

So. What did I miss? Is there a low-impact and well-supported way to support Oracle Objects from Ruby and/or Rails? If not Oracle, does Rails offer good object type support for any object-relational database management system?

Answer 1

Rails has, by design, very strong "opinions" on how things are supposed to work.

In the case of ActiveRecord: It presents a simple API to work with traditional relational databases, since that is what web applications normally need. It does go as far as treating that database as a dumb store for simple types and define all relations and logic on the ruby side.

Supporting other technologies, such as object databases, would make the normal use case more complex, so ActiveRecord does not.

There is support in the Rails community for NoSQL (document and key-value) stores, but I have not seen anything for object databases yet.

That said, Rails 3 has moved much of the ActiveRecord functionality into separate modules. You could use those to roll out your own Oracle Object storage layer. However, I guess that the effort would outweigh the benefits in most cases.

Also, if your particular problem is that you need subtypes, have a look at Rails "Single Table Inheritance" feature, which allows you to have a single database table where each row has its own ActiveRecord type.

So, you are not missing anything in particular. If you like Rails, I'd suggest trying to work with the existing ecosystem. If you really think you need an object database, maybe you are better off trying to find a framework that has that support baked in already.