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

Ruby Apps Nitro
1

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

2

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

3

On Nov 29, 2007 11:49 AM, Judson L. [email protected] 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

4

On Nov 29, 2007 11:49 AM, Judson L. [email protected] 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… :slight_smile:

[minor
Judson L. [email protected]**20070320020302] {
hunk ./og/lib/og/model.rb 499

  •  include Og::SchemaInheritanceBase

  •  include Og::Mixin::SingleTableInherited

}

[refactor: optimization of field_maps

5

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

6

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