[Nitro] OG vs Active Record

Jonathan Buch john at oxyliquit.de
Thu Aug 23 12:22:39 EDT 2007


Hi,

> Is my understanding of the OG<->db relationship way off the mark to
> observe that how much custom code is required will depend on how
> sophisticated OG is in generating/processing SQL? This of course is a
> function of how much development is done.

I tend to see the 'write custom queries' as an optimization.  When I
need more speed, optimization is done.

> Or is there something about mapping objects to db's that means it'll
> never be possible to (efficiently) do the more sophisticated things?

Well, the ORM can't go around 'guessing' your intentions.  There must
be a clever way to tell the ORM what exactly you need.  Best is, for
one purpose only 1 query, not 250.

The way on how to 'specify your needs' varies of course.  I'm sure
someone very clever will come up with a way to create a 'auto vew
creator' using a special DSL and thus make it much more comfortable
to 'specify your needs'.

"I want this, then please join that table, add some information from
"that, aggregrate some information and finally do some calculations
"based on the results in a subquery."

For more sophisticated SQL there is just more information needed, and
where does that information come from if not from the programmer.

Anyway, that is my reason to write my VIEWs myself instead of letting
some machine do horribly hacked together queries.

>> you're correct in that you need custom queries sometimes, but that is
>> quite horrible there within the model.  ;)
>>
>> May I say that VIEWs are really useful?  Please, also consider my Tip
>> on http://www.oxyliquit.de/tip/31 , life can only go better.  :P
>
> Thanks for pointing out your tip.
> I've a question about defining an object that OG recognizes as a view
> rather than a table, I'll post in another thread since it starts to
> get off topic.

Og doesn't recognize views at all, it doesn't think that far atm.

Idea:

class MyUserView
   is Og::VIEW(MyUser)

   att_accessor :a, :b, String

   set_view <<-SQL
     SELECT foo.a,blah.b FROM foo, blah
   SQL
end

MyUserView.all

>> I agree on that it only 'moves' the problem, but...  I think it's
>> just a whole lot cleaner.
>
> If OG could recognise a 'view' object then it'd all be back in the model?

MyUserView.view_source # => MyUser


I have a slightly similar implementation here (which I shared with someone
on IRC already who implemented it more like my current idea) which I needed
for work.
It has a few glitches (and thus I won't push to Og main), but it's actually
very simple to implement, like 4 lines added.  It also autogenerates the
view itself (unlike my earlier tip where you have to do that yourself).

But, coupling a VIEW to another object is sometimes not that clever.  Views
might be completely detached, not having to do much with the original
purpose of the used models....  *hrm*

Sorry for the unhelpfulness of this post, it's really just ideas blabbered
out loud.

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png


More information about the Nitro-general mailing list