Forum: Nitro [OG] enchant Question: klass.table or klass::OGTABLE

Hi Devs,
This may be a dumb question, but which of the following is the correct
way to access the table name of an Og managed class:
 a) klass.table
 b) klass::OGTABLE

In fact just what does the following comment in
sql.rb:SqlStore#enchant mean/relate to?

      # FIXME: jl: Remove references to table, then remove these 5 lines

It makes me think the above choice it's been resolved to use
klass::OGTABLE, _but_  _only_ in Og's code. Correct?
So internal use of klass.table is deprecated but the table attribute
remains for user code.  Correct?

Mark

Looking back at that comment, I believe what I meant was that, rather 
than
use OGTABLE, and assign it based on the klass, instead, just use 
klass.table(),
and be sure that klass.table for SchemaInheritence works.  In general, 
it
was my thinking at the time that klass.table should be the correct way 
to
determine the table name, although in a perfect world, client code 
wouldn't
ever need to, except in unusual circumstances - like migrating out of 
Og, or
trying to understand the library better.

Looking at the code now, later, I can't find Og::SchemaInheritenceBase 
at
all.  Has STI been abandoned?

Judson

On Nov 29, 2007 11:49 AM, Judson Lester <nyarly@gmail.com> wrote:
> Looking back at that comment, I believe what I meant was that, rather than
> use OGTABLE, and assign it based on the klass, instead, just use
> klass.table(), and be sure that klass.table for SchemaInheritence works.  In
> general, it was my thinking at the time that klass.table should be the
> correct way to determine the table name, although in a perfect world, client

Thanks for the insight, that is useful.

> code wouldn't ever need to, except in unusual circumstances - like migrating
> out of Og, or trying to understand the library better.
>
> Looking at the code now, later, I can't find Og::SchemaInheritenceBase at
> all.  Has STI been abandoned?

would be good to have an issue tracker...
Anyway, for the record, the following spec requires a flexmock and why
might be worth thinking about?
I'm cheating a little by not doing a full blown Og.start -
DummyDatabase is a sub-class of DbiAdapter, with some methods
overridden to allow me to see the sql statements generated.

  describe DbiAdapter, "#table_exists?" do
    before(:each) do
      @db = DummyDatabase.new
      flexmock(@db).should_receive(:tables).and_return([:a,
:b]).times(3).ordered
    end

    it "should use Database#tables if available" do
      @db.table_exists?(:a).should be_true
      @db.table_exists?(:b).should be_true
      @db.table_exists?(:c).should be_false
    end

  end

Mark

Please disregard that last post - wrong spec... I'll try and dig up
the example I was thinking of....
Mark

On Nov 29, 2007 11:49 AM, Judson Lester <nyarly@gmail.com> wrote:
> Looking back at that comment, I believe what I meant was that, rather than
> use OGTABLE, and assign it based on the klass, instead, just use
> klass.table(), and be sure that klass.table for SchemaInheritence works.  In
> general, it was my thinking at the time that klass.table should be the
> correct way to determine the table name, although in a perfect world, client
> code wouldn't ever need to, except in unusual circumstances - like migrating
> out of Og, or trying to understand the library better.
>
> Looking at the code now, later, I can't find Og::SchemaInheritenceBase at
> all.  Has STI been abandoned?

I just noticed this... :)
http://www.nitroproject.org/uploads/posts/2007/3/r...

[minor
Judson Lester <nyarly@gmail.com>**20070320020302] {
hunk ./og/lib/og/model.rb 499
-      include Og::SchemaInheritanceBase
+      include Og::Mixin::SingleTableInherited
}

[refactor: optimization of field_maps

That's hilarious.  All I can say is: March was a long time ago.