Hi all, I have had to integrate a rails application with a legacy database. I must say it worked out rather well, but now I need to create a separate Rails app that also needs to use much of the same functionality that the first app did. I started to separate out all the code I used in the first app into a plugin that I can include in the new application (and any additional in the future). With the exception of a separate database connection in database.yml all the code for this are simple ActiveRecord models. Is this the best direction for this? The other issue I started to notice was that I should probably use some sort of namespaces to prevent class conflicts. I started prefixing all the models, currently 10 models in 10 files, with "Legacy::", but that broke all the associations between these models. Of which, there are a lot. Is there a better way to handle this too? As on last bonus, as all these models use a custom database connection is it best to just add that connection to the database.yml file, or (can) should I put that connection information somewhere else so it is better associated with the plugin itself? Thanks for any help in advance. Peer -- 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 -~----------~----~----~----~------~----~------~--~---
Hi Peer,> database connection in database.yml all the code for this are simple > ActiveRecord models. Is this the best direction for this?I agree. Plugins are perfect for grouping together sets of model classes.> The other issue I started to notice was that I should probably use some > sort of namespaces to prevent class conflicts. I started prefixing all > the models, currently 10 models in 10 files, with "Legacy::", but that > broke all the associations between these models. Of which, there are a > lot. Is there a better way to handle this too?Yes, in your ActiveRecord associations specify ":class_name", something like this: class Foo < ActiveRecord::Base has_many :bar, :class_name => ''Legacy::Bar'', :foreign_key => ''foo_id'' end This is only necessary for models that aren''t part of the namespace: all the "Legacy::" models can associate with each other without any prefixes.> As on last bonus, as all these models use a custom database connection > is it best to just add that connection to the database.yml file, or > (can) should I put that connection information somewhere else so it is > better associated with the plugin itself?I don''t know if this would work best for you, but one approach would be to make a parent class for all your other models. Set the database connection in that parent class. One caveat: if your ActiveRecord associations are across models in different databases you might have problems, because of the way Rails does joins etc. behind the scenes. So if you encounter problems you can do your relationships manually instead of using ActiveRecord''s associations: you can write methods in your models that find associated records, etc. Regards, Dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
urbanus wrote:>> The other issue I started to notice was that I should probably use some >> sort of namespaces to prevent class conflicts. I started prefixing all >> the models, currently 10 models in 10 files, with "Legacy::", but that >> broke all the associations between these models. Of which, there are a >> lot. Is there a better way to handle this too? > > Yes, in your ActiveRecord associations specify ":class_name", > something like this: > > class Foo < ActiveRecord::Base > has_many :bar, :class_name => ''Legacy::Bar'', :foreign_key => > ''foo_id'' > end > > This is only necessary for models that aren''t part of the namespace: > all the "Legacy::" models can associate with each other without any > prefixes. >When I first did set it up I didn''t put all the models in a subfolder and that caused some complaints while testing. Once I moved all the models into a subfolder the prefix issue disappeared, within those models that is.>> As on last bonus, as all these models use a custom database connection >> is it best to just add that connection to the database.yml file, or >> (can) should I put that connection information somewhere else so it is >> better associated with the plugin itself? > > I don''t know if this would work best for you, but one approach would > be to make a parent class for all your other models. Set the database > connection in that parent class. >That is exactly what I did. All the parent class has in it is an "establish_connection" call and all the models inherit from it. My question was more related to where the connection information (user, host, password) should reside. As these applications will only be internal I don''t think having this info in the database.yml is such a bad idea.> One caveat: if your ActiveRecord associations are across models in > different databases you might have problems, because of the way Rails > does joins etc. behind the scenes. So if you encounter problems you > can do your relationships manually instead of using ActiveRecord''s > associations: you can write methods in your models that find > associated records, etc. >Thanks for the reminder. I definitely had to deal with this when building the original application. I just want to say how awesome this is turning out. It only took about 20 minutes to get everything setup and working. Now, just to get the original application switched to use the new plugin. Thanks all Peer -- 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 Apr 13, 6:57 am, "urbanus" <urba...-f4ka5phDm1zYtjvyW6yDsg@public.gmane.org> wrote: [...]> Yes, in your ActiveRecord associations specify ":class_name", > something like this: > > class Foo < ActiveRecord::Base > has_many :bar, :class_name => ''Legacy::Bar'', :foreign_key => > ''foo_id'' > end > > This is only necessary for models that aren''t part of the namespace: > all the "Legacy::" models can associate with each other without any > prefixes.[...] This is the ORM for an anti-RoR database? thanks, Thufir --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---