[Nitro] Og update

[James Britt]

craig duncan wrote:
 >
 > I've spent a fairly small amount of time so far trying to use
 > ActiveRecord, and none at all yet with OG.  I decided that,
 > conceptually, i preferred the AR approach of generating methods from an
 > existing database schema.  After working with it a little, though, i
 > have to say that i really don't like AR.  Creating various associations
 > (has_one, belongs_to, etc) seems much more cumbersome to me than what i
 > would hope to be able to do by simply writing a sql query wrapped inside
 > a method where i can assign the values returned from the query to ruby
 > variables.  This seems like it should be simpler to code, easier to work
 > with, and more flexible.  There may actually be a way to do this with AR
 > but questions to the mailing list haven't resulted in anything very
 > helpful to me at the stage i'm at and the documentation is dreadful.  I
 > wonder if OG could provide the kind of interface i'm alluding to?

Ironic that you might get a better Rails answer on the Nitro list, but 
here goes:

Rails has find_by_sql:

     sql = "select t.* from tags t  where t.tag in ( #{tag_set_str} ) "
     tags = Tag.find_by_sql( sql )

# Now tags has a set of Tag objects.

I have a Rails app that is probably 90% SQL, as the API associations 
where simply too weak to get me what I wanted.  That may have changed in 
the current version, but given some of the quirky SQL I've had to write 
(due, in large part, to short comings with MySQL), I have a hard time 
believing that the dynamic SQL generation is anything near optimized.

This may be a good example a reason one might choose Rails over Nitro, 
or vice versa, or simply roll their own code.  One of my apps started 
using Rails, but I hacked around quite a bit; it is now mainly Catapult 
+  AR  + lots of SQL and object munging.  Ruby makes this easy, and in 
retrospect I don't see that using Rails gained me much (other than an 
education in Rails).  With about the same amount of effort I could have 
simply done the O/R mapping myself and just writing a fairly 
straightforward database-backed Web service.  And have fewer files 
laying around.

It's also the sort of thing where I don't think Nitro would be a good 
fit, because I already know and have the data, I need to hand code the 
SQL, and I'm just rendering result sets in assorted markup based on 
various queries.  There are very few objects, and there is very little 
business logic; it's mostly "Look this up and wrap RDF around the 
results."

For other applications, the objects are the main thing, with the data 
being something of residual artifacts.  In those cases, I don't really 
want to think in SQL, I want to think in object relationships.  I think 
Kirbybase is an example of this.

I can see, though, were one might need to go to the metal, as it were, 
and run specific SQL against the database to get the correct object set 
(and ensure it happens efficiently).  I think, though, that this makes 
it harder to write cross-Og adapter code, as  not all persistence layers 
use SQL (or use it the same way).

But, being coupled to a particular persistence layer is often a design 
choice one has to make as the requirements become clearer.  In my 
experience, database-hopping is rare, and trying to build this in is 
typically not worth the overhead.



James