Heya :) This was a GREAT post... I''ll comment (briefly) below...> -----Original Message-----> From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-> bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Rick Bradley> Sent: Wednesday, August 17, 2005 11:27 AM> To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> Subject: [Rails] O<->RM (was "Re: Comparing Ruby on Rails to Django")>[ lots of good stuff snipped ]> In short, if you want to reduce clarification footprint (and hence> reduce coupling, bugs, promote maintainability, etc.) then you are> better off maintaining your database with database tools, and letting> your OO layer ask the database how it should behave.I do see where your coming from on this... essentially the points you make are: * Database design and optimization is a complex and feature full beast for a reason * Building all the smarts needed to do that stuff right in a database generation tool is a big problem * Considering those points, it makes sense to hand tune your DB, and let the object frame work query it So far. I agree. However, when I follow those thoughts, suddenly I realize why I am reluctant to commit to Rails for non trivial projects. * Rails is fundamentally ignorant of all the stuff you mentioned. IT makes no use and as far as I know ignores triggers, stored procedures, compound keys and views. In short, your well thought out problem with building the smarts into DB generation is ALSO a discussion of why automatically inferring the model from a query of the DB is >also< difficult and complex. Now, in trivial cases this doesn''t matter and both Django and Rails will do well. But in a complex case a flexible, programmer edited "map" between object model and DB structure will be essential (as in Hibernate). Soulhuntre ---------- http://www.girl2.com <http://www.girl2.com/> - my girls http://www.the-estate.com <http://www.the-estate.com/> - my legacy http://wiki.thegreybook.com <http://wiki.thegreybook.com/> - my project http://weblog.soulhuntre.com <http://weblog.soulhuntre.com/> - my thoughts _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Rick Bradley
2005-Aug-18 22:22 UTC
Re: O<->RM (was "Re: Comparing Ruby on Rails to Django")
* Soulhuntre (soulhuntre-xtZVmrYH4z1ZroRs9YW3xA@public.gmane.org) [050818 03:25]:> * Rails is fundamentally ignorant of all the stuff you mentioned. IT > makes no use and as far as I know ignores triggers, stored procedures, > compound keys and views.Rails does ignore triggers (as they are a database level construct of which the OO layer should rightfully be ignorant). Rails allows for easy use of stored procedures, it simply doesn''t allow one to write stored procedures w/in Rails -- no problem there as there is presumably a reason one is writing code inside the database as opposed to placing it in the application. Views are transparent to Rails -- they simply look like tables to Rails. Rails doesn''t specify views, primarily because they are a database-level abstraction/optimization, of which the application layer should rightfully be ignorant. As for compound keys, Rails doesn''t stop the database from using them, and some may argue that Rails should have constructs identifying them. That, I believe, falls into the legacy-database criticism arena which is an ongoing discussion about how Rails can/should be used. All these "Rails doesn''t handle X" features reduce coupling, meaning that when changes are made at the lower database layer those changes do not "shotgun" up through the application layer as yet more changes to make (and break).> In short, your well thought out problem with building the smarts into > DB generation is ALSO a discussion of why automatically inferring the > model from a query of the DB is >also< difficult and complex.Inferring the model from a DB can be difficult and complex, especially when one gets into model support for complex legacy database constructs. Following my compression analogy, the variability in legacy database construction makes it difficult for the clarification language parser (and I use the word parser loosely here again) to unify/compress the legacy database constructs, so more clarification is going to be necessary. The weight of my contentions, though, is that much of the database complexity is database-layer concerns, which shouldn''t be exposed to the object/application layer. The further complexity (especially when dealing with databases of widely ranging capabilities) comes in inferring foreign keys, compound keys, etc., which don''t map easily to clean OO idioms in many cases. There one needs to introduce more clarification "code". But, my realization was that it''s better to compress more and clarify less than to try to express the entirety of the database-level information at the (impedance-)mismatched OO layer. This statements excludes the middle of Hibernate-style configuration, which we''re about to go back to discussing...> Now, in trivial cases this doesn''t matter and both Django and Rails > will do well. But in a complex case a flexible, programmer edited > "map" between object model and DB structure will be essential (as in > Hibernate).Let me say what I think Hibernate''s mapping brings to the table that pure OO-level or DB-level clarification languages may lack: - query extraction: akin to i18n for queries, a mapping can extract SQL strings from the code into a common area. This doesn''t have to happen at a mapping-file level, as i18n techniques are easily adapted to this problem and can be applied at the OO-level, but typically some external resource file exists, and if there is a mapping file it might as well be there. As a slight criticism of Hibernate in particular, I''ve noticed that the mapping doesn''t fully solve the DB dialect problem, as database function calls are passed straight through to the database (e.g., a call to now() on postgres doesn''t work well with Oracle which has no now(), by default, but the call is passed down, regardless). - arbitrary mapping from fields (or faux fields) to class methods: this is particularly handy in less dynamic languages such as Java, but in languages like Ruby this functionality can be expressed much more succinctly in the OO language itself. - clarification of complex legacy database constructs (non-uniform keys, poorly "designed" tables, etc.): to get support for strange and complex cases there is little to do but increase the amount of clarification "code" written. Hibernate chooses to put this information in the mapping file. Given the stiff nature of the Java language that''s potentially a better choice than placing it into Java itself, but XML is incredibly verbose, and XML steps outside the Java type system. [0] While I cannot proffer written examples yet (as noone has been bothered enough yet to implement them), it is clear to me that in every case listed above there is a more flexible and more succinct Ruby OO alternative that could do what Hibernate does with its mapping files in a fraction of the clarification code, opening up the DB features to OO reuse. The first case (i18n-style query factoring) is trivial -- merely use an indirection layer to look up the queries to be manipulated, given that we already know the database dialect in use: I''ve done it in Perl, it would be even easier in Ruby. The mapping functionality I list is done routinely in Rails and is so simple that it''s of little worth mentioning. The fact that Java makes this such an ordeal (and ends up, with Hibernate, subverting the type system to get a solution at all) is more telling than that Hibernate proposes a (verbose) solution. It''s only the last factor where Hibernate mappings still offer a tangible benefit, and there is no reason why the information contained in the mapping file could not be expressed in a terse Ruby DSL that would work in ActiveRecord. More difficult is using a different ORM pattern than the Active Record pattern in Rails. There''s no reason why someone couldn''t do this, but noone seems to have been compelled to do so yet. DHH is not likely to be doing legacy apps any time soon, so someone else will be needed to take on the headache of legacy DB wrangling. Anyway, if from the mapping file we eliminate everything that could be easily expressed (more succinctly) in a Rails DSL or methods currently (or with a small tweak to do i18n-style dialecting) then all that is left is a handful of XML lines that specify clarifications relating to what I keep calling "legacy database" concerns. Those lines are more tersely expressed in a Ruby DSL (and more powerfully since the OO reuse techniques can be applied to them) than in an XML mapping file. The only problem then remains the limited scope of the Active Record pattern. Create an ORM library for Rails that is more general than AR [2] and there''s nothing that Hibernate and its mapping files would do that Rails'' ORM wouldn''t do, and more succinctly. But, then again, noone seems particularly inspired to add another non-AR ORM library to Rails, so anyone''s guess is as good as mine as to how things would come out. ;-/ [0] which, broken as it is [1] is one of the few defensible reasons proponents give for using Java [1] considering Java''s designers'' knowledge of the field, flagrant nose-thumbing at Hindley-Milner is patently inexcusable (I''m reminded of Bill Hicks'' rants against advertisers when I think of Bill Joy, James Gosling, etc., bending over to make the senseless compromises made in Java) [2] I''m not saying this wouldn''t have side-affects in application code, merely that it could conceivably be done: if nothing else, once could convert Hibernate''s Java code to Ruby (and then rewrite it the Ruby Way to get rid of a lot of unnecessary baggage) Rick -- http://www.rickbradley.com MUPRN: 544 | Saturday for or random email haiku | less one-way with a | 14-day advance purchase.
Heya :)> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Rick Bradley > Sent: Thursday, August 18, 2005 6:23 PM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] O<->RM (was "Re: Comparing Ruby on Rails to Django") > > Rails does ignore triggers (as they are a database level construct of > which the OO layer should rightfully be ignorant).In some ways yes, but not in all cases. This gets nto a "best practices" thing, so I''ll concede it and we can move on :)> Rails allows for > easy use of stored procedures, it simply doesn''t allow one to write > stored procedures w/in RailsReally? I know of course that you could write code of your own to over-ride methods with code that might call a stored procedure but I would be surprised to find out at this point that Rails would "automagically" use stored procedures without intervention.> it in the application. Views are transparent to Rails -- they simply > look like tables to Rails.Ok, not having worked with Rails in any environment other than MySQL I didn''t know. Cool!> While I cannot proffer written examples yet (as noone has been bothered > enough yet to implement them), it is clear to me that in every case > listed above there is a more flexible and more succinct Ruby OO > alternative that could do what Hibernate does with its mapping files in > a fraction of the clarification code, opening up the DB features to OO > reuse.I agree. I think a Ruby specific mapping mechanism would be much more readable and succinct. For that matter (going back to the stored procedure thing) Rails effectively does have one - it just comes down to "over ride the default code if you don''t like it" - thus spreading the mapping throughout the code instead of centralizing it. One thing is for sure - it is certainly getting interesting out there! Soulhuntre ---------- http://www.girl2.com - my girls http://www.the-estate.com - my legacy http://wiki.thegreybook.com - my project http://weblog.soulhuntre.com - my thoughts