From: "S. Potter" Date: 2008-02-13T02:13:04+09:00 Subject: Re: Comparing Active Record VS Datamapper...? howard wrote: >> try defining a column with a default of 'now()' or anything which uses � >> db functions. �note that you cannot use Time.now from inside ruby � >> because, unlike internal db functions, this will not ensure a � >> consistent now across all fields inside a transaction. Actually for Ruby programmers as opposed to people that only know APIs in Ruby, extending the APIs for specific use-cases is very painless. To get people started to solve this though (as I do not have permission to post the whole code in public yet) you would override the relevant connection adapters (e.g. ActiveRecord::ConnectionAdapters::PostgreSQLAdapter, etc.) and redefine the #column method to accept (in our case) :default_sql, which wouldn't escape the SQL string passed to it. It is good practice to override all standard connection adapters even if you do not use them, because you never know who might start using SQLite3 on the team in development or test environments. Especially if you roll these AR extensions out on an IT-wide or cross-project basis. If I were you I would look at the sexy migrations plugin code for more pointers if you don't want to look inside AR source. > You can easily do that in Sequel: > DB.create_table :posts do > ... > timestamp :stamp, :default => :now[] > end > > Sorry, couldn't resist :-) > sharon The problem with Sequel as far as I understand it, is that you have to be disciplined enough to create the Domain Object layer yourself to abstract away more complex model logic and it appears to be a lot more code to hide the Sequel code for non-trivial scenarios. Otherwise you get a very stripped down DB-oriented (rather than object-oriented) database adaption API for your application. If you do not create a Domain Object layer, you end up with all the logic (controller AND model logic) in the controller layer, which is only maintainable when you have very trivial model logic. This doesn't work in richer model logic environments. Both AR and DM can cope well in rich Domain Object scenarios though which one of these is the better fit depends on other variables. So comparing Sequel to AR and/or DM is like comparing apples and oranges. If you like oranges better, that is fine, but let's not lose sight of this fact that Sequel is not really in side by side competition with these two libraries. On a positive note for Sequel, I have heard that for non-complex mappings it is lighterweight, but I have not seen any real benchmark numbers to support this. However, intuitively it seems plausible as it doesn't hide very much of the database, which in most of my development work is not a benefit. If you are looking for a ORM library in Ruby that has everything all there, you will be disappointed. As you can see there are pros and cons for each library and will depend on the following (depending on how your team weighs each one): * Maturity * Schema (e.g. legacy non-isomorphic schema, etc.) * Migration Needs (i.e. for limited support DM might be fine, for data migration support AR or Sequel might fit the bill) * Design (e.g. are you looking for a library that provides you with a Domain Object to hide non-trivial model logic inside, if so DM or AR is for you. If not Sequel might work) * Skillset (e.g. if you have more AR knowledge, then you might be better off going this route, etc.) * Performance (although I haven't seen any benchmarks out there on this one yet?) There is no silver bullet and anyone that tells you there is, either has a very simple situation that doesn't test all these variables (and possibly more variables I haven't mentioned?) or is biased!:) Thanks, Susan PS I accept that most of my experiences are with AR and that is what I know best, but I also realize there are AR limitations. However, I choose to solve those limitations myself for project/architecture-specific needs. -- Posted via http://www.ruby-forum.com/.