[Nitro] Og update
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.
> 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.
> 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