Somewhat of a newbie question I must admit, but... I''m trying to push Rails within our organization but I''m not convinced it would be a good fit - basically this is a very DB-centric shop, most of the developers use PL/ (or PG) SQL and the vast majority of the logic sits in stored procedures. As the lone web guy who must build on top of this, I would like to use Rails to shorten my development time. I''ve only just started looking into Rails, but I keep running into the emphasis on the ORM bit, and that''s just not applicable to us. We use j2ee right now: tomcat, velocity, webwork, etc., but *not* hibernate nor any other ORM; what I typically do is just build a class for each db package with a static function for each stored proc. For each proc, if it returns a primitive, fine - if it returns a cursor, I wraps this up by hand (trivially) into a value object, or an array thereof. This works great for us, so I''m not looking for an argument about that.. So my question is: does it make sense at all to use Rails without the ORM? It looks right now to us like it''s a pretty central component - is Rails then maybe not really applicable for our situation? Or could we just ignore the ORM and do something similar as we do now (i.e. class per package, method per proc, value objects, etc.), using I suppose the Ruby equivalent of perl''s DBI stuff? Any general ruminations, as well as specific tips would be much appreciated... (My apologies if something like this has already been addressed, I could not find anything after much googling...) thanks, Ossie
Somewhat of a newbie question I must admit, but... I''m trying to push Rails within our organization but I''m not convinced it would be a good fit - basically this is a very DB-centric shop, most of the developers use PL/ (or PG) SQL and the vast majority of the logic sits in stored procedures. As the lone web guy who must build on top of this, I would like to use Rails to shorten my development time. I''ve only just started looking into Rails, but I keep running into the emphasis on the ORM bit, and that''s just not applicable to us. We use j2ee right now: tomcat, velocity, webwork, etc., but *not* hibernate nor any other ORM; what I typically do is just build a class for each db package with a static function for each stored proc. For each proc, if it returns a primitive, fine - otherwise if it returns a cursor, I wrap this up by hand (trivially) into a value object, or an array thereof. This works great for us, so I''m not looking for an argument about that.. So my question is: does it make sense at all to use Rails without the ORM? It looks right now to us like it''s a pretty central component - is Rails then maybe not really applicable for our situation? Or could we just ignore the ORM and do something similar as we do now (i.e. class per package, method per proc, value objects, etc.), using I suppose the Ruby equivalent of perl''s DBI stuff? Any general ruminations, as well as specific tips would be much appreciated... (My apologies if something like this has already been addressed, I could not find anything after much googling...) thanks, Ossie
On Apr 12, 2005 4:53 AM, Ossie Guy <ossieguy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Somewhat of a newbie question I must admit, but... I''m trying to push > Rails within our organization but I''m not convinced it would be a good > fit - basically this is a very DB-centric shop, most of the developers > use PL/ (or PG) SQL and the vast majority of the logic sits in stored > procedures. As the lone web guy who must build on top of this, I would > like to use Rails to shorten my development time.Ouch. I''ve been in an ''all logic in stored procedures'' shop before. They up with ended 57000 stored procedures in one app. Not fun ;/.> I''ve only just started looking into Rails, but I keep running into the > emphasis on the ORM bit, and that''s just not applicable to us. We use > j2ee right now: tomcat, velocity, webwork, etc., but *not* hibernate > nor any other ORM; what I typically do is just build a class for each > db package with a static function for each stored proc. For each proc, > if it returns a primitive, fine - otherwise if it returns a cursor, I > wrap this up by hand (trivially) into a value object, or an array > thereof. This works great for us, so I''m not looking for an argument > about that.. > > So my question is: does it make sense at all to use Rails without the > ORM? It looks right now to us like it''s a pretty central component - > is Rails then maybe not really applicable for our situation? Or could > we just ignore the ORM and do something similar as we do now (i.e. > class per package, method per proc, value objects, etc.), using I > suppose the Ruby equivalent of perl''s DBI stuff?Absolutely. ActiveRecord (not really an ORM) can be completely ignored if you so wish. I have several applications now without a DB component. Wrappers around some shell scripts, reading files off disk etc. Your case is the same, but instead of non-db models, it''s raw DBI calls. What I''ve done in the past is write the ruby code I need for the non-db model and drop it into vendor/. Then built the rest of the application as normal, though you lose some of the ''magically require modified files'' stuff. There may be a better way to structure it. Just bear in mind you''ll lose all the validations support, and you''ll have to write your own validation methods. Though this is pretty easy if you''re good with RegExps.> Any general ruminations, as well as specific tips would be much appreciated... > > (My apologies if something like this has already been addressed, I > could not find anything after much googling...)It''s been mostly covered under topics like ''rails without a db''.> thanks, > Ossie > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
* Michael Koziarski (koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050411 14:55]:> Just bear in mind you''ll lose all the validations support, and you''ll > have to write your own validation methods. Though this is pretty easy > if you''re good with RegExps.Note that you should be able to include the validations functionality in your own classes fairly readily. After all, active_record.rb just does: [...] require ''active_record/validations'' [...] ActiveRecord::Base.class_eval do include ActiveRecord::Validations [...] to get access to the validation funcionality (really, all functionality) itself. Rick -- http://www.rickbradley.com MUPRN: 673 | of resources while random email haiku | intentionally killing | large numbers of people.
On Apr 12, 2005 8:00 AM, Rick Bradley <rick-xSCPAUIMY+WN9aS15agKxg@public.gmane.org> wrote:> * Michael Koziarski (koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050411 14:55]: > > Just bear in mind you''ll lose all the validations support, and you''ll > > have to write your own validation methods. Though this is pretty easy > > if you''re good with RegExps. > > Note that you should be able to include the validations functionality in > your own classes fairly readily. After all, active_record.rb just does:Yeah, that works well for field level validation. But things like validates_uniqueness_of won''t exactly function very well when you''re not dealing with a db backed model.> [...] > require ''active_record/validations'' > [...] > ActiveRecord::Base.class_eval do > include ActiveRecord::Validations > [...] > > to get access to the validation funcionality (really, all functionality) > itself. > > Rick > -- > http://www.rickbradley.com MUPRN: 673 > | of resources while > random email haiku | intentionally killing > | large numbers of people. >-- Cheers Koz
This is what i use: http://rafb.net/paste/results/cBCOyu70.html> Yeah, that works well for field level validation. But things like > validates_uniqueness_of won''t exactly function very well when you''re > not dealing with a db backed model.-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://www.hieraki.org - Open source book authoring http://blog.leetsoft.com - Technical weblog
* Michael Koziarski (koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050411 16:10]:> Yeah, that works well for field level validation. But things like > validates_uniqueness_of won''t exactly function very well when you''re > not dealing with a db backed model.I agree -- but I''ll have to say it''s nice to have the option when your storage technique of choice can be tweaked to fit the AR semantics. Rick -- http://www.rickbradley.com MUPRN: 993 | correct, channels. The random email haiku | line in turns into rear | channel line out.
Ossie Guy wrote:> what I typically do is just build a class for each > db package with a static function for each stored proc. For each proc, > if it returns a primitive, fine - otherwise if it returns a cursor, I > wrap this up by hand (trivially) into a value object, or an array > thereof. This works great for us, so I''m not looking for an argument > about that..I would agree with the other posts and say that Rails still provides many benefits outside of ActiveRecord. If your decent at doing meta-programming in Ruby (which is easy compared to other languages) you can get Ruby to do much of what you described above automatically for your packages. So make a class much like ActiveRecord::Base that will read your database packages and get lists of your stored procedures, then general methods for each stored procedures. So you could have something like: class Customer < ActiveDBPackage::Base end Then define ActiveDBPackage such that it will read all stored procedure specs in the "Customer" db package then generates your methods that wrap the stored procedures. It might be a little work to develop this but then you can add support for each database package very easily (2 lines of code). You then also have the option of overriding a wrapped stored procedure if the standard wrapping doesn''t suit your needs. Just a suggestion, Eric _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails