How are class variables persisted using Activerecord? Cheers, Ganesh Gunasegaran -- 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 -~----------~----~----~----~------~----~------~--~---
Hey, Could you elaborate on the question? Perhaps post an example of your question so we can help you. Steve --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
If you are asking about actual class and class instance variables
here''s a brief explanation. If you''re talking about variables
that
show up in view templates or somewhere else then please be more
descriptive with your question.
Class variables in ruby persist throughout a whole class hierarchy.
class A
@@a = 1
def self.a ; @@a ; end
end
A.a # => 1
class B < A
@@a = 2
end
A.a # => 2
B.a # => 2
Class instance variables on the other hand exist in the context of a
single class definition.
class C
@c = 1
def self.c ; @c ; end
end
C.c # => 1
class D < C
@c = 2
end
C.c # => 1
D.c # => 2
Zach
On Apr 26, 12:27 pm, Ganesh Gunasegaran <rails-mailing-l...@andreas-
s.net> wrote:> How are class variables persisted usingActiverecord?
>
> Cheers,
> Ganesh Gunasegaran
>
> --
> Posted viahttp://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
-~----------~----~----~----~------~----~------~--~---
Stephen Bartholomew wrote:> Hey, > > Could you elaborate on the question? Perhaps post an example of your > question so we can help you. > > SteveHmm, Let us say I have a User class that inherits from ActiveRecord::Base class User < ActiveRecord::Base end The User has two attributes :name and :age class CreateUsers < ActiveRecord::Migration def self.up create_table :users do |t| t.column :name, :string end end def self.down drop_table :users end end All the attributes are persisted and are also available thro the instance variable @attributes. ex: user = User.create(:name => "gg", :age => 25) p user.name #=> "gg" p user.attributes["name"] #=> "gg" So effectively the instance variables are persisted in the model. Let us say I need to track the number of users created. So basically I have to maintain the number of users value in the Class level (I understand that we can also store it in a separated model/table, but storing it in the class level makes more sense.) Ignoring error checking "User" model will now look like class User < ActiveRecord::Base @@no_of_users = 0 def initialize @@no_of_users += 1 end def User.no_of_users @@no_of_users end end user1 = User.new p User.no_of_users # => 1 user2 = User.new p User.no_of_users # => 2 The problem is, we are not persisting the class variable in the database, so once we restart the application, the @@no_of_users is reset back to 0. My question is how we can persist the class variable @@no_of_users in the database.. Any thoughts? Cheers, Ganesh Gunasegaran. -- 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 -~----------~----~----~----~------~----~------~--~---
Maybe dumb question... why not just use count? That''ll be up to date. If you want to avoid doing a lot of queries, then you can query any time you don''t have a cached value, and otherwise just increment the cached value. -- 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 -~----------~----~----~----~------~----~------~--~---
I get the feeling the OP is coming from the Java / Hibernate realm. In Rails, ActiveRecord objects are not persisted across requests, thus you can''t do what you''re talking about here. And frankly, I''m with Bryan, why aren''t you just using #count? Jason On 4/26/07, Bryan Duxbury <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Maybe dumb question... why not just use count? That''ll be up to date. If > you want to avoid doing a lot of queries, then you can query any time > you don''t have a cached value, and otherwise just increment the cached > value. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
Sorry, hit "send" to soon.
Also, I need to correct one of your deductions. The attributes on an
ActiveRecord object are not instance variables. So your example:
ex: user = User.create(:name => "gg", :age => 25)
p user.name #=> "gg"
p user.attributes["name"] #=> "gg"
User does not have @name and @age. Insead, user.name ends up calling
#method_missing which ActiveRecord uses to search the @attributes hash for
the appropriate key and value. So instance variables are not kept around at
all, meaning you can add variables to your model without worrying about
ActiveRecord or the database engine complaining about "unknown
column".
Jason
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
I can see why Ganesh is thinking this - class variables will persist over requests if you''re using something like mongrel as you''ll be running from the same ruby instance. However, on restarting mongrel the ruby environment is reloaded, knocking out the class variables. For this reason, using class would be inaccurate. Most sites will be running on more than one ruby instance meaning that the count will be out of whack. Class variables are ok for un-changing config vars but not suitable for this task. As suggested, I''d use count. Steve --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
It sounds like you have a misconception of database persistence. An instance of a model object represents a database table row. Think of the class as the table column headers: id name password 1 Bill 78d877s8d 2 Steve 8873jdi873837 Now how would you write SQL to store data in the headers (table definition)?> Let us say I need to track the number of users created. So basically I > have to maintain the number of users value in the Class level (I > understand that we can also store it in a separated model/table, but > storing it in the class level makes more sense.)So from a model-relational mapping system this actually doesn''t make since. On Apr 26, 2:57 pm, "Jason Roelofs" <jameskil...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Sorry, hit "send" to soon. > > Also, I need to correct one of your deductions. The attributes on an > ActiveRecord object are not instance variables. So your example: > > ex: user = User.create(:name => "gg", :age => 25) > p user.name #=> "gg" > p user.attributes["name"] #=> "gg" > > User does not have @name and @age. Insead, user.name ends up calling > #method_missing which ActiveRecord uses to search the @attributes hash for > the appropriate key and value. So instance variables are not kept around at > all, meaning you can add variables to your model without worrying about > ActiveRecord or the database engine complaining about "unknown column". > > Jason--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Bryan Duxbury wrote:> Maybe dumb question... why not just use count? That''ll be up to date.Hi Guys, The example I gave was just for illustration. As you guys pointed out, we can just use User.count in this example. But that is not my question here. What if I am crazy and actually wanted to persist a class variable in the database. Wondering how other ORM''s handle class variables... Cheers, Ganesh Gunasegaran. -- 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 -~----------~----~----~----~------~----~------~--~---
On 4/26/07, Ganesh Gunasegaran <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Bryan Duxbury wrote: > > Maybe dumb question... why not just use count? That''ll be up to date. > > Hi Guys, > > The example I gave was just for illustration. > > As you guys pointed out, we can just use User.count in this example. But > that is not my question here. What if I am crazy and actually wanted to > persist a class variable in the database. Wondering how other ORM''s > handle class variables... > > Cheers, > Ganesh Gunasegaran.Well, the answer is: you don''t. I don''t think a single ORM will let you do this, as it just doesn''t make any sense. Jason --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Jason Roelofs wrote:> On 4/26/07, *Ganesh Gunasegaran* <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org > <mailto:rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>> wrote: > > > Bryan Duxbury wrote: > > Maybe dumb question... why not just use count? That''ll be up to date. > > Hi Guys, > > The example I gave was just for illustration. > > As you guys pointed out, we can just use User.count in this example. But > that is not my question here. What if I am crazy and actually wanted to > persist a class variable in the database. Wondering how other ORM''s > handle class variables... > > Cheers, > Ganesh Gunasegaran. > > > > Well, the answer is: you don''t. I don''t think a single ORM will let you > do this, as it just doesn''t make any sense. > > Jason >I think what Jason''s getting at is this: ORM means *Object* relational mapping... it''s about mapping the state of an *object* to a row in the db. A class variable is not part of an object''s state, so it doesn''t make sense to map into a table holding object data. If you find yourself needing to persist information about all objects of a given class, them maybe there''s a new model there. However, in the case of counting, yeah that''s just information you can observe from the state of the table... i.e. a count query. If you''re concerned about the performance of count queries, rails has an automagic column you can add to your model/table to cache that information. b --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Ben Munat wrote:> I think what Jason''s getting at is this: ORM means *Object* relational > mapping... it''s about mapping the state of an *object* to a row in the > db. A class variable is not part of an object''s state, so it doesn''t > make sense to map into a table holding object data.Well, A class is an object in ruby :P Getting the point, thanks guys... Cheers, Ganesh Gunasegaran. -- 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 -~----------~----~----~----~------~----~------~--~---
Ganesh, I think the difference is that in Rails there is not really an attempt to provide a generic ORM solution. Rails is not objects first with a database as an afterthought or just a way to save in-mrmory objects to disk. Mostly those solutions fail anyway (in my experience). The Rails mind-set is that data is stored in a database and the Rails layer does not attempt to hide that or to provide a complete persistence model for everything you can do in Ruby. Rails provides a Ruby layer to access the relational database. The difference in mind- set is a bit subtile but important. Rails does not hide SQL or try to hide the database. It just provides a layer to make that access easier for common cases. The storage model is relational not objects. Michael On Apr 26, 2:21 pm, Ganesh Gunasegaran <rails-mailing-l...@andreas- s.net> wrote:> Ben Munat wrote: > > I think what Jason''s getting at is this: ORM means *Object* relational > > mapping... it''s about mapping the state of an *object* to a row in the > > db. A class variable is not part of an object''s state, so it doesn''t > > make sense to map into a table holding object data. > > Well, A class is an object in ruby :P > > Getting the point, thanks guys... > > Cheers, > Ganesh Gunasegaran. > > -- > Posted viahttp://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 -~----------~----~----~----~------~----~------~--~---
Things that are persisted in the database are instances of subclasses of ActiveRecord::Base. User is a subclass of ActiveRecord::Base, however User itself is an instance of Class, not AR:Base, and so can''t be persisted using active record. If you do want to save that sort of info add a new model for that purpose. Fred -- 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 -~----------~----~----~----~------~----~------~--~---