Hi, I''m looking at developing a reasonably complex web application, where most of the complexity actually lays in the database and the queries I need run on it. Some "classes" or models need to consist of an assembly of several tables. It would be trivial enough for me to code these queries in SQL, but as far as I understand Rails is trying to hide the database as much from me as possible. I have only a general idea of how Rails works but want to give it a try for this project, mainly because I want to get some experience with it. I''m just wondering how fit it is for the task. Is it a simple matter of building the models correctly or will I need to do more to bend Rails to do my bidding? ;o) Any ideas welcome. Cheers, Dav --~--~---------~--~----~------------~-------~--~----~ 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 David AcctiveScaffold plugin may just be the solution for you :-) On Oct 4, 10:24 am, David Zentgraf <dec...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > > I''m looking at developing a reasonably complex web application, where > most of the complexity actually lays in the database and the queries > I need run on it. Some "classes" or models need to consist of an > assembly of several tables. It would be trivial enough for me to code > these queries in SQL, but as far as I understand Rails is trying to > hide the database as much from me as possible. I have only a general > idea of how Rails works but want to give it a try for this project, > mainly because I want to get some experience with it. I''m just > wondering how fit it is for the task. Is it a simple matter of > building the models correctly or will I need to do more to bend Rails > to do my bidding? ;o) > > Any ideas welcome. > > Cheers, > Dav--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
David Zentgraf wrote:> Hi, > > I''m looking at developing a reasonably complex web application, where > most of the complexity actually lays in the database and the queries > I need run on it. Some "classes" or models need to consist of an > assembly of several tables. It would be trivial enough for me to code > these queries in SQL, but as far as I understand Rails is trying to > hide the database as much from me as possible. I have only a general > idea of how Rails works but want to give it a try for this project, > mainly because I want to get some experience with it. I''m just > wondering how fit it is for the task. Is it a simple matter of > building the models correctly or will I need to do more to bend Rails > to do my bidding? ;o) > > Any ideas welcome. > > Cheers, > DavI assume that it is an existing database, or otherwise you could just create the tables to match your models. The simplest option otherwise is to create a view for each model by selecting the data you need. If you follow Rails'' naming conventions with the views in your database and your attributes in the models, Rails will treat the view exactly as it would a table, and the database will take care of the rest. (Note if you''re using Oracle, you will need to add triggers to update the underlying tables, and PostgreSQL requires some additional lines.) Cheers, Matt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
David Zentgraf wrote:> Hi, > > I''m looking at developing a reasonably complex web application, where > most of the complexity actually lays in the database and the queries > I need run on it. Some "classes" or models need to consist of an > assembly of several tables. It would be trivial enough for me to code > these queries in SQL, but as far as I understand Rails is trying to > hide the database as much from me as possible. I have only a general > idea of how Rails works but want to give it a try for this project, > mainly because I want to get some experience with it. I''m just > wondering how fit it is for the task. Is it a simple matter of > building the models correctly or will I need to do more to bend Rails > to do my bidding? ;o)Without specific examples it''s impossible for us to tell you how much work it might be to get Rails to do what you would like it to do. -- Michael Wang --~--~---------~--~----~------------~-------~--~----~ 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. Oct 2007, at 11:50, fotn wrote:> I assume that it is an existing database, or otherwise you could just > create the tables to match your models. The simplest option otherwise > is to create a view for each model by selecting the data you need. If > you follow Rails'' naming conventions with the views in your database > and your attributes in the models, Rails will treat the view exactly > as it would a table, and the database will take care of the rest. > (Note if you''re using Oracle, you will need to add triggers to update > the underlying tables, and PostgreSQL requires some additional lines.)Actually no, I''m still completely in the planning stages of the project and am building my tables the way I''d usually do it using PHP/ SQL for example. I am looking at postgres as my database, mostly because it includes CHECK() functions. Am I tackling this the wrong way for using Rails? Example: I''ll have three or four different types of "objects", which are all very related and just variations of the same idea. In my database I have table A, B and C. A contains information common to all "objects", whereas B and C contain various extra information in a many-to-one relationship to A. Depending on whether there are entries in B or C referencing the object in A, the object can be considered to be of a different type and have different uses within the application. It''s rather trivial to do SQL queries on that like SELECT * FROM a WHERE id IN (SELECT a_id FROM b WHERE [condition])... etc. How would I go about this in rails? Can I abstract these queries to such a degree in views? Cheers. --~--~---------~--~----~------------~-------~--~----~ 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. Oct 2007, at 11:45, CCH wrote:> > Hi David > > AcctiveScaffold plugin may just be the solution for you :-)I''ll have a look whether that can do anything for me, thanks. :) --~--~---------~--~----~------------~-------~--~----~ 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 almost sounds like you are after either polymorphism or single- table inheritance. An example of polymorphism is on the Rails wiki: http://wiki.rubyonrails.org/rails/pages/ UnderstandingPolymorphicAssociations Single-table inheritance is a slightly simpler method wherein all data resides in a (coincidentally) single table but is viewed differently depending on the object type: http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance Regarding creating the tables with SQL statements. Many, if not most Rails developers are using migrations. That way you can have a versionable schema that is independent of the backbone. HTH On Oct 3, 2007, at 8:44 PM, David Christopher Zentgraf wrote:> > On 4. Oct 2007, at 11:50, fotn wrote: > >> I assume that it is an existing database, or otherwise you could just >> create the tables to match your models. The simplest option otherwise >> is to create a view for each model by selecting the data you need. If >> you follow Rails'' naming conventions with the views in your database >> and your attributes in the models, Rails will treat the view exactly >> as it would a table, and the database will take care of the rest. >> (Note if you''re using Oracle, you will need to add triggers to update >> the underlying tables, and PostgreSQL requires some additional >> lines.) > > Actually no, I''m still completely in the planning stages of the > project and am building my tables the way I''d usually do it using PHP/ > SQL for example. I am looking at postgres as my database, mostly > because it includes CHECK() functions. > Am I tackling this the wrong way for using Rails? > > Example: > I''ll have three or four different types of "objects", which are all > very related and just variations of the same idea. In my database I > have table A, B and C. A contains information common to all > "objects", whereas B and C contain various extra information in a > many-to-one relationship to A. Depending on whether there are entries > in B or C referencing the object in A, the object can be considered > to be of a different type and have different uses within the > application. > It''s rather trivial to do SQL queries on that like SELECT * FROM a > WHERE id IN (SELECT a_id FROM b WHERE [condition])... etc. > How would I go about this in rails? Can I abstract these queries to > such a degree in views? > > Cheers. > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
David Christopher Zentgraf wrote:> Example: > I''ll have three or four different types of "objects", which are all > very related and just variations of the same idea. In my database I > have table A, B and C. A contains information common to all > "objects", whereas B and C contain various extra information in a > many-to-one relationship to A. Depending on whether there are entries > in B or C referencing the object in A, the object can be considered > to be of a different type and have different uses within the > application. > It''s rather trivial to do SQL queries on that like SELECT * FROM a > WHERE id IN (SELECT a_id FROM b WHERE [condition])... etc. > How would I go about this in rails? Can I abstract these queries to > such a degree in views?Active Record supports both Single Table Inheritance where you basically mash all the information into a single table and Polymorphic Associations where the extra information is kept in separate tables (like your example) with pointers to them in the main table, without needing to write raw SQL. -- Michael Wang --~--~---------~--~----~------------~-------~--~----~ 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. Oct 2007, at 12:53, Michael Wang wrote:> Active Record supports both Single Table Inheritance where you > basically > mash all the information into a single table and Polymorphic > Associations where the extra information is kept in separate tables > (like your example) with pointers to them in the main table, without > needing to write raw SQL.On 4. Oct 2007, at 12:51, s.ross wrote:> It almost sounds like you are after either polymorphism or single- > table inheritance. An example of polymorphism is on the Rails wiki: > > http://wiki.rubyonrails.org/rails/pages/ > UnderstandingPolymorphicAssociations > > Single-table inheritance is a slightly simpler method wherein all > data resides in a (coincidentally) single table but is viewed > differently depending on the object type: > > http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance > > Regarding creating the tables with SQL statements. Many, if not most > Rails developers are using migrations. That way you can have a > versionable schema that is independent of the backbone.Thanks both. I''ll give that a shot. I know about migrations, I just like to think in raw SQL during the planning stages of my projects. ;o) That may actually be the biggest hurdle I''ll have to overcome for working in Rails... Cheers, Dav --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks for the detailed explanation. Every tutorial I had a look at so far began with modelling the tables using SQL in one way or another and than building Rails on top of that, getting it to reference the correct tables. Apparently that''s the wrong way to go... If I can do all the references from A to B and vice-versa using classes in Rails I think I''ll be happy. Regarding that, what''s actually the best way to start an application? Writing a migration, creating the DB from it, scaffolding the models and controllers, then doing the has_many :B, :C? Or will those relations be scaffolded automatically if I''m migrating correctly? Chrs, Dav On 4. Oct 2007, at 13:09, Matt Redmond wrote:> You might want to look at it from a slightly different angle. The > many-to-one relationship is specified easily in Rails using: > > class A < ActiveRecord::Base > ... > has_many :B, :C > ... > end > > class B < ActiveRecord::Base > ... > belongs_to :A > ... > end > > etc. > > You can specify conditions in your Rails queries by > > a = A.new( [some params] ) > bs = B.find_all_by_a_id(some_id, :conditions => [...]) > if a.bs.include?(bs) ... > > Syntax is probably a little off, since it will deal with arrays, > but the idea is pretty simple. > > Rails is smart enough to work out all the details. It''s easy to > check if A has an entry in B or C or both, so you can just wrap it > in an ''if'' clause if you need to. > > The other option is to create different klass references, and have > B and C inherit from A, e.g. > > class A < ActiveRecord::Base > ... > end > > class B < A > ... > end > > etc. > > Check out the sitepoint book (pdf is free now); that''s what I > started with -- it covers associations pretty well. Best reference > is of course Agile Web Development With Rails by Thomas & Heinemeir > Hansson. If you don''t have it, I''d recommend it if you plan to do > much Rails development. > > Haven''t used Postgres, so not sure what check functions actually do > -- but based on what I''ve googled, I''d say you don''t need to worry. > Rails has built in validation for format and inclusion, > presence_of, etc, and callbacks which allow you to massage/reformat > data before save or before validation too. > > Hope that helps. > > Cheers, > Matt--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
David Christopher Zentgraf wrote:> Thanks for the detailed explanation. > Every tutorial I had a look at so far began with modelling the tables > using SQL in one way or another and than building Rails on top of > that, getting it to reference the correct tables. Apparently that''s > the wrong way to go... > If I can do all the references from A to B and vice-versa using > classes in Rails I think I''ll be happy. > > Regarding that, what''s actually the best way to start an application? > Writing a migration, creating the DB from it, scaffolding the models > and controllers, then doing the has_many :B, :C? Or will those > relations be scaffolded automatically if I''m migrating correctly? > > Chrs, > Dav >Hi David, Rails/ Ruby are all about agility, so, the idea is to do frequent iterations, adding a little bit at each iteration. I would start by creating a migration for one of the models and then creating the model for it. If I was eager to see what it looked like, I''d create a controller/ scaffold to get it up so that I can enter some things into the table. Then, I''d go after the next model and so on. Once both sides of a relationship exist, I''d add the relationships and add the view/ controller code for managing insertions, etc. (I haven''t yet used ActivScaffold so I''m not full sure what all it handles). The second edition of Agile Web Development with Rails does go through a full-fledged application at the start of the book. While it''s a real-enough application, it opens up all the key features of Rails. If you decide to commit to Rails, it is a worthwhile investment. There''s another book from SitePoint that is available free of charge right now (58 days and counting down) and it should cover the main concepts too. Alternatively, look for online tutorials. There are a couple of IBM Developer Works which take you through your first application that are not bad, either. Cheers, Mohit. 10/4/2007 | 12:28 PM. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Excellent starter indeed, thanks a bunch! Downloading the sitepoint book as well as we speak. Tutorial wise, I followed the awfully written OnLamp "Rolling with RoR" tutorial linked from http://www.rubyonrails.org/docs and a few others, but none seemed to have explained the basic getting-started idea as poignant as you just did. I didn''t buy any books on Rails just yet since I first wanted to find out whether it''s the right tool for the job... Best, Dav On 4. Oct 2007, at 13:38, Matt Redmond wrote:> Not sure what tutorials your using, but my understanding is you > should only do that if you have an existing database that you want > to build a rails app on top of. Generally, after you''ve created > your database (no tables), start by creating your model, which will > create the related migration automatically (after creating your > database). For example, > > ruby script/generate Cat > > will automatically generate the model > > cat.rb > > and the migration > > 001_create_cats.rb > > If we then have toys for the cat, we can go > > ruby script/generate Toy > > which creates toy.rb and 002_create_toys.rb. > > Then in your cat model... > > class Cat < ActiveRecord::Base > has_many :toys > end > > and your toy model... > > class Toy < ActiveRecord::Base > belongs_to :cat > end > > and in your migrations > > (create_cats) > create_table cats do |t| > t.column :name, :string > t.column ... > end > > (create_toys) > create_table toys do |t| > t.column :cat_id, :integer > t.column ... > end > > Then run rake db:migrate to create the cats and toys tables with > the columns you''ve specified. Again, check out the sitepoint book, > it''s a good starter for Rails newbies. > > If you need tables without an id column, you can specify them by > > create_table [table_name] {:id => false} do |t| > end > > These are useful for habtm relationships. Hope that is a good starter. > > Cheers, > Matt > > On 04/10/2007, at 1:51 PM, David Christopher Zentgraf wrote: > >> Thanks for the detailed explanation. >> Every tutorial I had a look at so far began with modelling the >> tables using SQL in one way or another and than building Rails on >> top of that, getting it to reference the correct tables. >> Apparently that''s the wrong way to go... >> If I can do all the references from A to B and vice-versa using >> classes in Rails I think I''ll be happy. >> >> Regarding that, what''s actually the best way to start an >> application? Writing a migration, creating the DB from it, >> scaffolding the models and controllers, then doing the >> has_many :B, :C? Or will those relations be scaffolded >> automatically if I''m migrating correctly? >> >> Chrs, >> Dav >> >> On 4. Oct 2007, at 13:09, Matt Redmond wrote: >> >>> You might want to look at it from a slightly different angle. The >>> many-to-one relationship is specified easily in Rails using: >>> >>> class A < ActiveRecord::Base >>> ... >>> has_many :B, :C >>> ... >>> end >>> >>> class B < ActiveRecord::Base >>> ... >>> belongs_to :A >>> ... >>> end >>> >>> etc. >>> >>> You can specify conditions in your Rails queries by >>> >>> a = A.new( [some params] ) >>> bs = B.find_all_by_a_id(some_id, :conditions => [...]) >>> if a.bs.include?(bs) ... >>> >>> Syntax is probably a little off, since it will deal with arrays, >>> but the idea is pretty simple. >>> >>> Rails is smart enough to work out all the details. It''s easy to >>> check if A has an entry in B or C or both, so you can just wrap >>> it in an ''if'' clause if you need to. >>> >>> The other option is to create different klass references, and >>> have B and C inherit from A, e.g. >>> >>> class A < ActiveRecord::Base >>> ... >>> end >>> >>> class B < A >>> ... >>> end >>> >>> etc. >>> >>> Check out the sitepoint book (pdf is free now); that''s what I >>> started with -- it covers associations pretty well. Best >>> reference is of course Agile Web Development With Rails by Thomas >>> & Heinemeir Hansson. If you don''t have it, I''d recommend it if >>> you plan to do much Rails development. >>> >>> Haven''t used Postgres, so not sure what check functions actually >>> do -- but based on what I''ve googled, I''d say you don''t need to >>> worry. Rails has built in validation for format and inclusion, >>> presence_of, etc, and callbacks which allow you to massage/ >>> reformat data before save or before validation too. >>> >>> Hope that helps. >>> >>> Cheers, >>> Matt >> >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> explained the basic getting-started idea as poignant as you just did.I think I wanted to say "to the point". Must''ve been distracted by the poignant foxes on http://www.rubyonrails.org/docs. ;o) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---