Pfister, Govinda
2005-Sep-08 06:45 UTC
AW: how to dynamically establish model relationships???
Hello Scott, thanks for your efforts to guide me to the right direction. I am myself new to ruby and rails. What I understand of your solution is that your are dynamically extending the model classes with class_eval. What I do not understand is why you are creating two moduls to extent the ActiveRecord::Base Class. The first one being RelationshipInstaller and within that the second module Installer. Why are you doing this? Govinda -----Ursprüngliche Nachricht----- Von: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] Im Auftrag von Ezra Zygmuntowicz Gesendet: Mittwoch, 7. September 2005 22:50 An: rorpostings-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Betreff: Re: [Rails] how to dynamically establish model relationships??? Nice one Scott- -Ezra On Sep 7, 2005, at 9:59 AM, scott moody wrote:> Govinda, > > I''ve thrown something together that might help you: > > ---file: rel_installer.rb > > module ActiveRecord > module RelationshipInstaller > def self.included(base) > base.extend(Installer) > end > module Installer > def install_relationships(relationships) > relationships.each do | class_name, assoc | > class_name.to_s.constantize.class_eval assoc > end > end > end > end > end > > ---end file > > - Put rel_installer.rb into your app''s lib directory. > - Put "require ''rel_installer.rb''" into your environment.rb file > > - Put a call to ''install_relationships'' into your plugin classes. > Example: > > class MyPlugin<<ActiveRecord::Base > install_relationships "MyMainModel"=>"has_many :my_plugins", > > "AnotherModel"=>"has_and_belongs_to_many :my_plugins" > end > > *When the class definition is executed* at startup, this code will > open up the classes with the given names as the keys in the > parameter hash and add the relationships given in the associated > values. So, in the above example, the MyMainModel will have a > has_many relationship to MyPlugin. > > - Note: In this implementation, the relationship will not be > executed until the plugin class is first referenced. You could do > this by simply iterating over your list of plugin class name > strings and executing: ''plugin_name.constantize'' where > ''plugin_name'' is a string that is the name of the model being > plugged-in. > > - Obviously, you have choose string delimeters that take into > account information embedded in the relationship parameter strings. > > This is the simplest implementation. You could be much smarter, but > hopefully this will give you an idea of what is possible. > > Note: I have only minimally tested this due to time constraints > (one simple check, actually), so do not put this into production > without a battery of tests. And, because I live in the USA, let me > add that this code is provided without warranty. Use at your own risk. > > Let me know if this helped you. > - Scott > > > > On 9/6/05, Pfister, Govinda <Govinda.Pfister-kyawv7ubMNaakBO8gow8eQ@public.gmane.org> wrote: > Hi, > > > I tried to find an answer to this topic in the archive, but couldn > ´t find anything. > > > I do develop a rails app, which can be extended by plugins/ > components. Those components have their own models. > > Those components interact with models of the base app, too. So I > have to establish relationships between models of my base app and > models of components I don´t know of in advance. The components are > registered with the app, when installed. So I can get the info of > installed components from the database. > > > I thought of a method, which establishes relationships dynamically > at object creation via initialize() and gets the necessary infos > from the database. > > > Can this be done? > > > Govinda > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-Ezra Zygmuntowicz Yakima Herald-Republic WebMaster 509-577-7732 ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Just a question regarding the handling of Timestamps by
ActiveRecord. Currently I have a Rails application configured to
handle dates and times in UTC. Additionally the PostgreSQL database
that Rails uses also has each timestamp attribute configured to store
them as UTC. Thus, I would expect that any date handled by Rails
(either through INSERT, UPDATE, or SELECT) would automatically be
inserted as the default_timezone (UTC) set in the environment.rb.
However, the development.log indicates that ActiveRecord is inserting
timestamps without any zone information, i.e.,
INSERT INTO [table] ("start", "name", "finish")
VALUES(''2005-09-08
00:00:00'', ''test'', ''2005-09-10
00:00:00'')
This means that if the timestamp is in EST, for example, it would be
inserted into the database incorrectly as a UTC date.
Obviously, a solution to this problem is to ensure that each date
being inserted is converted to UTC before you save it, but I''d rather
do it properly than reinvent the wheel.
Is this a fault in ActiveRecord or the application?
Cheers,
Robert
Hi Govinda, The modules aren''t absolutely necessary. You could write it this way: --- file rel_installer.rb ActiveRecord::Base.class_eval do def self.install_relationships(relationships) relationships.each do | class_name, assoc | class_name.to_s.constantize.class_eval assoc end end end --- end When this is executed via a ''require'', the install_relationships class method will be added to ActiveRecord::Base and the resulting functionality should be identical. Breaking code down into modules is done because it helps in managing complexity and name scoping. I''m currently writing an act_as module that not only adds new class and instance methods to a multiple classes, but it also creates a secondary, nested act_as function, defines a new class, and adds that act_as to the new class. I can''t imagine what that code would look like without the nested module pattern. Setting things up from the beginning to handle complexity-growth (as a convention) makes it quicker to evolve the code. Using a standard template that can evolve with increased complexity makes it easier to understand the code at a later date. BTW, I''m new to Ruby, too -- just started a few weeks ago. The pattern presented in the first email is one that I''ve seen in a number of Rails metaprogramming examples including Dema''s most excellent acts_as_taggable extension. If you understand his code (and assuming I follow the rules implicit in the pattern he''s developing), then understanding my act_as module will be much less time consuming. I wouldn''t mind seeing the template formally documented so that we can all just plug our functionality into it. So, no, it is not necessary, but I believe it is a good idea. On 9/8/05, Pfister, Govinda <Govinda.Pfister-kyawv7ubMNaakBO8gow8eQ@public.gmane.org> wrote:> > Hello Scott, > > thanks for your efforts to guide me to the right direction. I am myself > new to ruby and rails. > > What I understand of your solution is that your are dynamically extending > the model classes with class_eval. > > What I do not understand is why you are creating two moduls to extent the > ActiveRecord::Base Class. The first one being RelationshipInstaller and > within that the second module Installer. Why are you doing this? > > Govinda > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Better handling of timezones is an issue that''s coming up more and more frequently (see a recent thread "Timezones / Locales"). I''m surprised that rails doesn''t pass the zone to the DB although I guess I''ve been insulated from that because I set my rails apps to use UTC (as you say you''ve done) *and* set the database process to be UTC as well. In mysql this is done by passing a --timezone=UTC arg when starting up the database. If you need to display/accept dates to/from the user you''ll need to convert the UTC values (obviously) but the chances are that your conversion will have to be to/from a DST-aware timezone like "Europe/London" rather than "GMT". I wrote code to handle this properly but I''m not in a position to release it. However, Philip Ross has apparently released some code that uses the Olsen timezone database (much like perl''s DateTime::Timezone). http://tzinfo.rubyforge.org HTH Trevor On 8-Sep-05, at 12:56 AM, Robert O''Farrell wrote:> Just a question regarding the handling of Timestamps by ActiveRecord. > Currently I have a Rails application configured to handle dates and > times in UTC. Additionally the PostgreSQL database that Rails uses > also has each timestamp attribute configured to store them as UTC. > Thus, I would expect that any date handled by Rails (either through > INSERT, UPDATE, or SELECT) would automatically be inserted as the > default_timezone (UTC) set in the environment.rb. > > However, the development.log indicates that ActiveRecord is inserting > timestamps without any zone information, i.e., > > INSERT INTO [table] ("start", "name", "finish") VALUES(''2005-09-08 > 00:00:00'', ''test'', ''2005-09-10 00:00:00'') > > This means that if the timestamp is in EST, for example, it would be > inserted into the database incorrectly as a UTC date. > > Obviously, a solution to this problem is to ensure that each date > being inserted is converted to UTC before you save it, but I''d rather > do it properly than reinvent the wheel. > > Is this a fault in ActiveRecord or the application? > > Cheers, > Robert > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails