[Nitro] Og update

James Britt james_b at neurogami.com
Fri Apr 22 11:00:01 EDT 2005

craig duncan wrote:
> George Moschovitis wrote:
>> Can you explain more what you want? An advantage of Og over AR is that
>> it automatically creates the correct schema for the associations (or
>> Relations as they are called in Og). The same happens with Mixins. For
>> example, Og automatically creates the table columns to support the
>> nested_sets pattern, thus fully encapsulating the pattern.
>> -g.
> a) i want something that's documented (reasonably well) so that even if 
> the way to use the feature is not entirely obvious or maybe even a 
> little difficult, i can still manage it without tearing my hair out.  
> Also, the difficulty (over what i could accomplish more simply) should 
> be worth the effort.
> b) if i can't easily (enough) figure out how a certain (powerful) 
> feature works and i know that what i want should be easily doable, then 
> there should be some alternate, probably not as powerful, but easy to 
> grasp, mechanism for accomplishing roughly the same thing.
> So, with ActiveRecord, what i've wanted to do is select (via multiple 
> joins) fields from a number of tables... not one by one but in a single 
> query that hits the database just once and returns a single result (this 
> is exactly what i would do if i were working directly in sql).  In 
> principle this seems very simple to me, and i perfectly well understand 
> how to write the sql.  My (fuzzier) notion of how this data will be 
> returned to me (since it doesn't map to any individual db table) was 
> some mechanism that would allow me to create a class with members giving 
> me access to each field returned from the query.  Maybe i should use a 
> view but i've been resisting that idea because i'm not clear how updates 
> would work and AR, in this instance, would be providing me with nothing 
> but the most limited capability and so... why bother?

Craig, I tried to reply privately to an earlier message, but it bounced. 
  I didn't want to turn this into Yet Another Rails List, but this may 
be of interest to George as a way of perhaps explaining some behavior.

I haven't checked this lately, but I recall that when I used custom SQL 
to fetch an object set in Rails, the properties of each object were 
determined by the fields requested, not the class making the request.


   sql = "select t.id as tag_id from tags t  "
   tag_ids = Tag.find_by_sql( sql )

would give a set of objects of class Tag, but each object would only 
have a single property, 'tag_id'  (though I generally use it to add new 
properties to objects when the extra info is useful in the view).

I believe that you can create arbitrary objects like this, though I'm 
unsure if there are restrictions or consequences based on what main 
class is used to run the query.

But I also suspect that writing something that just returned smart 
Structs or something, based on the result set, would be simple.

Given a result set, one would just need to loop over each row and 
dynamically create a new object with properties mapped to field names.


obj_set = ObjectSet.get( "select t.name as name from tags t,
                p.url as url from posts p
                where p.id = t.post_id" )

# obj_set  should now have objects with properties 'name' and 'url'

There have been some recent threads on ruby-talk about dynamically 
adding attributes, or one could first dynamically construct a class def 
based on the field names in the result set, then create an instance of 
this for each row.

> Further, i have just run into the situation where one of my ancillary 
> tables is selected from via *two* key fields in my main table.  So far, 
> with AR, i know of no (non-kludgy) way of doing this, nor have i yet 
> received any answer from the Rails mailing list.
> Overall, what i want to do is really *quite* simple.  I have a very 
> normalized set of tables.  And yet it is proving (to me) amazingly 
> difficult to even understand the approach i'm supposed to take with AR 
> regarding these various issues (which is, admittedly, pretty much a 
> documentation problem).

Rails can be overkill.  AR may be overkill.  Creating objects from a 
result set is trivial.
> As far as what you've said about automatically creating the Relations, i 
> have no idea how this would work, so i can't say if it would provide the 
> means to do what i'm trying to do.
> craig
> P.S.  After looking at such a lot of really poor documentation (not from 
> the standpoint of what's expected from an IBM reference manual, but from 
> virtually any other) i've had the thought of volunteering to write 
> documentation... if someone would be willing to *explain* to me how the 
> thing to be documented works (iteratively, of course).  It's a truism 
> but anyone who knows how something works too well and/or learned it too 
> long ago, is virtually incapable of doing good documentation, because 
> they skip over too much that is so obvious to them that it exists 
> beneath the level of conscious awareness.

I started writing my Nitro tutorial as a way to help me learn how to use 
it.  I basically tried to start off with the simplest case, see how to 
do something, then gradually add features based on likely use cases.

I know from experience that documenting one's own work can be hard 
precisely because you lose track of what is intuitive and what isn't, 
which I think may be an argument for using obvious method names, and 
maybe following comment-driven development


More information about the Nitro-general mailing list