Forum: Ruby on Rails Referencing 'constant' record in db

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Colin L. (Guest)
on 2009-05-20 12:31
(Received via mailing list)
I have a table where one of the records is a constant record that I keep
finding myself referencing the id of in code such as
if item.id == Item.named_scope_for_constant_record.id
where the named scope involves a db query.

I thought it would be a good idea to use a constant for this, so in the
Item
model:
class Item<ActiveRecord::Base
  CONSTANT_RECORD_ID = named_scope_for_constant_record.id
 ..
end

Then I can reference Item::CONSTANT_RECORD_ID which is determined when
the
class is loaded.

This works fine in my application, but in my tests it appears the class
is
loaded before the fixtures as the find fails.  It is ok if I run 'ruby
test/unit/mytest.rb' but not if I 'rake test'.

Is my analysis of what is happening correct?  If so is there a better
way of
achieving the desired effect?

Colin
Colin L. (Guest)
on 2009-05-21 11:35
(Received via mailing list)
Any thoughts anyone?

Colin

2009/5/20 Colin L. <removed_email_address@domain.invalid>
Stephan W. (Guest)
on 2009-05-21 13:01
Colin L. wrote:
> Any thoughts anyone?
>
> Colin
>
> 2009/5/20 Colin L. <removed_email_address@domain.invalid>

I guess here are two, but your question looks vague.



Does

 item.id == Item.named_scope_for_constant_record.id

not become

  "the item satisfies the condition of the
named_scope_for_constant_record" ?



If for the Item class there is just this one special record, can you
force the id to be simply 0 by manipulating the database?



Stephan
Colin L. (Guest)
on 2009-05-21 13:17
(Received via mailing list)
2009/5/21 Stephan W. <removed_email_address@domain.invalid>

>
>
I am trying to avoid a db query each time I reference the (constant) id
when
the application is running, that was the idea of looking it up when the
class is loaded and saving in a constant (which does not work in test
mode
as the fixtures have not always been loaded when the class is loaded)


>
>
> If for the Item class there is just this one special record, can you
> force the id to be simply 0 by manipulating the database?
>

My initial solution was to have a well-known id for the special record.
The
problem with this in testing is that one has to then include the special
record with that id explicitly in the fixture. One cannot then make use
of
the automatic fixup of habtm tables using the names of the fixture
records
and so have to manually provide fixtures for the habtm join tables.
Plus
the idea of a record in the db having a well-known id is a bit yucky.

Colin
Roy P. (Guest)
on 2009-05-21 19:09
(Received via mailing list)
First, consider whether it's worth worrying about this--it may be that
rails' and/or the db's caching mechanisms make this not such a perf
issue.

That said, would it be feasible to not store this record in the db at
all?  Just make the constant a free-standing AR object?  Something like:

class MyModel < AR::Base
  def MyModel.constant_record
    @@constant_record ||= new(:bibbity => "bobbity", :boo => "foo")
  end
end

HTH,

-Roy
________________________________

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Colin L.
Sent: Thursday, May 21, 2009 2:17 AM
To: removed_email_address@domain.invalid
Subject: [Rails] Re: Referencing 'constant' record in db




2009/5/21 Stephan W. <removed_email_address@domain.invalid>



        Colin L. wrote:
        > Any thoughts anyone?
        >
        > Colin
        >
        > 2009/5/20 Colin L. <removed_email_address@domain.invalid>


        I guess here are two, but your question looks vague.



        Does


         item.id == Item.named_scope_for_constant_record.id


        not become

         "the item satisfies the condition of the
        named_scope_for_constant_record" ?




I am trying to avoid a db query each time I reference the (constant) id
when the application is running, that was the idea of looking it up when
the class is loaded and saving in a constant (which does not work in
test mode as the fixtures have not always been loaded when the class is
loaded)




        If for the Item class there is just this one special record, can
you
        force the id to be simply 0 by manipulating the database?



My initial solution was to have a well-known id for the special record.
The problem with this in testing is that one has to then include the
special record with that id explicitly in the fixture. One cannot then
make use of the automatic fixup of habtm tables using the names of the
fixture records and so have to manually provide fixtures for the habtm
join tables.  Plus the idea of a record in the db having a well-known id
is a bit yucky.

Colin





        Stephan
        --
        Posted via http://www.ruby-forum.com/.









GHC Confidentiality Statement

This message and any attached files might contain confidential
information protected by federal and state law. The information is
intended only for the use of the individual(s) or entities originally
named as addressees. The improper disclosure of such information may be
subject to civil or criminal penalties. If this message reached you in
error, please contact the sender and destroy this message. Disclosing,
copying, forwarding, or distributing the information by unauthorized
individuals or entities is strictly prohibited by law.
Stephan W. (Guest)
on 2009-05-21 19:40
Colin L. wrote:
> 2009/5/21 Stephan W. <removed_email_address@domain.invalid>
>
>>
>>
> I am trying to avoid a db query each time I reference the (constant) id
> when
> the application is running, that was the idea of looking it up when the
> class is loaded and saving in a constant (which does not work in test
> mode
> as the fixtures have not always been loaded when the class is loaded)
>

I meant it is not clear what the nature of this special record is, and
what conditions you have.

>>
>>
>> If for the Item class there is just this one special record, can you
>> force the id to be simply 0 by manipulating the database?
>>
>
> My initial solution was to have a well-known id for the special record.
> The
> problem with this in testing is that one has to then include the special
> record with that id explicitly in the fixture. One cannot then make use
> of
> the automatic fixup of habtm tables using the names of the fixture
> records
> and so have to manually provide fixtures for the habtm join tables.
> Plus
> the idea of a record in the db having a well-known id is a bit yucky.

How about adding this method to your Item class:

  # is this the special record "named_scope_for_constant_record" ?
  def special?
    @@special_record_id ||=  Item.named_scope_for_constant_record.id
    self.id == @@special_record_id_id
  end

There is a thread-issue around using ||= (
http://coderrr.wordpress.com/2009/04/29/is-not-thr...
) but that doesn't matter here.

Now you can even stub the special? method. Also, if the condition for
special? changes you just change the method.

Stephan

> Colin
Colin L. (Guest)
on 2009-05-21 20:30
(Received via mailing list)
2009/5/21 Stephan W. <removed_email_address@domain.invalid>

> > mode
> >>
> > the idea of a record in the db having a well-known id is a bit yucky.
>
> How about adding this method to your Item class:
>
>  # is this the special record "named_scope_for_constant_record" ?
>  def special?
>    @@special_record_id ||=  Item.named_scope_for_constant_record.id
>    self.id == @@special_record_id_id
>  end
>

Of course, I should have thought of using a global variable rather than
a
constant.  I didn't because I generally consider global variables to be
evil.  I think this may be the first time for many a year that I have
found
a good use for one.  Though really, though technically it is a global
variable, it is being used as a constant.

Problem solved, many thanks for helping

Colin
Roy P. (Guest)
on 2009-05-21 20:50
(Received via mailing list)
At the risk of being nitpicky, @@variables are not globals--they are
class variables.  Globals vars start with a $.

________________________________
From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Colin L.
Sent: Thursday, May 21, 2009 9:30 AM
To: removed_email_address@domain.invalid
Subject: [Rails] Re: Referencing 'constant' record in db

2009/5/21 Stephan W.
<removed_email_address@domain.invalid<mailto:removed_email_address@domain.invalid>>

Colin L. wrote:
>
I meant it is not clear what the nature of this special record is, and
what conditions you have.

> of
> the automatic fixup of habtm tables using the names of the fixture
> records
> and so have to manually provide fixtures for the habtm join tables.
> Plus
> the idea of a record in the db having a well-known id is a bit yucky.

How about adding this method to your Item class:

 # is this the special record "named_scope_for_constant_record" ?
 def special?
   @@special_record_id ||=
Item.named_scope_for_constant_record.id<http://Item.named_scope_for_constant_record.id>
   self.id<http://self.id> == @@special_record_id_id
 end

Of course, I should have thought of using a global variable rather than
a constant.  I didn't because I generally consider global variables to
be evil.  I think this may be the first time for many a year that I have
found a good use for one.  Though really, though technically it is a
global variable, it is being used as a constant.

Problem solved, many thanks for helping

Colin


There is a thread-issue around using ||= (
http://coderrr.wordpress.com/2009/04/29/is-not-thr...
) but that doesn't matter here.

Now you can even stub the special? method. Also, if the condition for
special? changes you just change the method.

Stephan

> Colin

--
Posted via http://www.ruby-forum.com/.






________________________________
GHC Confidentiality Statement

This message and any attached files might contain confidential
information protected by federal and state law. The information is
intended only for the use of the individual(s) or entities originally
named as addressees. The improper disclosure of such information may be
subject to civil or criminal penalties. If this message reached you in
error, please contact the sender and destroy this message. Disclosing,
copying, forwarding, or distributing the information by unauthorized
individuals or entities is strictly prohibited by law.
Colin L. (Guest)
on 2009-05-21 22:27
(Received via mailing list)
2009/5/21 Pardee, Roy <removed_email_address@domain.invalid>

>  At the risk of being nitpicky, @@variables are not globals--they are
> class variables.  Globals vars start with a $.
>

Yes of course, I am still getting the hang of ruby.  I think my comments
still apply, though not quite as strongly.  I suppose if I wrap it in a
class method I can probably live with my conscience.

Of course my whole concept of having a 'special' record is a bit yucky.
I
think maybe some refactoring is in order to improve the whole design.

Colin
Robert W. (Guest)
on 2009-05-22 20:50
Colin L. wrote:
> Yes of course, I am still getting the hang of ruby.  I think my comments
> still apply, though not quite as strongly.  I suppose if I wrap it in a
> class method I can probably live with my conscience.

Not necessarily. I see nothing wrong with using class variables. In Java
they are used all the time and are called "Fields" otherwise known as
static variable. Java actually doesn't have actual constants. A
"constant" in Java would be a static final variable. Declaring it static
makes it a variable on the class and final makes it immutable (unable to
change once initialized).

I think you're still confusing class variable and globals. Globals break
encapsulation, class variables do not.
This topic is locked and can not be replied to.