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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Any thoughts anyone? Colin 2009/5/20 Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>> 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 > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Colin Law wrote:> Any thoughts anyone? > > Colin > > 2009/5/20 Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>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 -- Posted via http://www.ruby-forum.com/.
2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>> > Colin Law wrote: > > Any thoughts anyone? > > > > Colin > > > > 2009/5/20 Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > 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/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
[mailto:rubyonrails-talk@googlegroups.com] On Behalf Of Colin Law
Sent: Thursday, May 21, 2009 2:17 AM
To: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: [Rails] Re: Referencing ''constant'' record in db
2009/5/21 Stephan Wehner
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
Colin Law wrote:
> Any thoughts anyone?
>
> Colin
>
> 2009/5/20 Colin Law
<clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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.
Colin Law wrote:> 2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > >> >> > 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-thread-safe-neither-is-hashnew-hk ) 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/.
2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>> > Colin Law wrote: > > 2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > > > >> > >> > > 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 >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-thread-safe-neither-is-hashnew-hk > ) 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/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
At the risk of being nitpicky, @@variables are not globals--they are class variables. Globals vars start with a $. ________________________________ From: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org [mailto:rubyonrails-talk@googlegroups.com] On Behalf Of Colin Law Sent: Thursday, May 21, 2009 9:30 AM To: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Subject: [Rails] Re: Referencing ''constant'' record in db 2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org<mailto:rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>> Colin Law wrote:> 2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org<mailto:rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>> > >> >> > 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<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-thread-safe-neither-is-hashnew-hk ) 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
2009/5/21 Pardee, Roy <pardee.r-go57ItdSaco@public.gmane.org>> 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> > ------------------------------ > *From:* rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org [mailto: > rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org] *On Behalf Of *Colin Law > *Sent:* Thursday, May 21, 2009 9:30 AM > *To:* rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > *Subject:* [Rails] Re: Referencing ''constant'' record in db > > 2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > >> >> Colin Law wrote: >> > 2009/5/21 Stephan Wehner <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> >> > >> >> >> >> >> > 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 >> > > 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-thread-safe-neither-is-hashnew-hk >> ) 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. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Colin Law 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. -- Posted via http://www.ruby-forum.com/.