Merge branch 'master' of github.com:rails/rails

This commit is contained in:
José Valim
2010-05-09 13:02:55 +03:00
7 changed files with 123 additions and 6 deletions

View File

@@ -80,7 +80,7 @@ module ActiveModel
#
# end
#
# Provivdes you with:
# Provides you with:
#
# AttributePerson.primary_key
# # => "sysid"

View File

@@ -1,5 +1,7 @@
*Rails 3.0.0 [beta 4/release candidate] (unreleased)*
* Aliases Date#sunday to Date#end_of_week. [fxn]
* Backports Date#>> from 1.9 so that calculations do the right thing around the calendar reform. [fxn]
* Date#to_time handles properly years in the range 0..138. [fxn]

View File

@@ -181,6 +181,7 @@ class Date
result = self + days_to_sunday.days
self.acts_like?(:time) ? result.end_of_day : result
end
alias :sunday :end_of_week
alias :at_end_of_week :end_of_week
# Returns a new Date/DateTime representing the start of the given day in next week (default is Monday).

View File

@@ -87,7 +87,7 @@ h4. Vendoring Gems
Rails now uses a +Gemfile+ in the application root to determine the gems you require for your application to start. This +Gemfile+ is processed by the "Bundler":http://github.com/carlhuda/bundler, which then installs all your dependencies. It can even install all the dependencies locally to your application so that it doesn't depend on the system gems.
More information: - "bundler README on Github":http://github.com/carlhuda/bundler
More information: - "bundler homepage":http://gembundler.com
h4. Living on the Edge

View File

@@ -2648,11 +2648,118 @@ NOTE: Defined in +active_support/core_ext/proc.rb+.
h3. Extensions to +Date+
...
h4. Calculations
All the following methods are defined in +active_support/core_ext/date/calculations.rb+.
INFO: The following calculation methods have edge cases in October 1582, since days 5..14 just do not exist. This guide does not document their behavior around those days for brevity, but it is enough to say that they do what you would expect. That is, +Date.new(1582, 10, 4).tomorrow+ returns +Date.new(1582, 10, 15)+ and so on. Please check +test/core_ext/date_ext_test.rb+ in the Active Support test suite for expected behavior.
h5. +Date.current+
Active Support defines +Date.current+ to be today in the current time zone. That's like +Date.today+, except that it honors +Time.zone_default+. It also defines +Date.yesterday+ and +Date.tomorrow+, and the instance predicates +past?+, +today?+, and +future?+, all of them relative to +Date.current+.
h5. Named dates
h6. +last_year+, +next_year+
The methods +last_year+ and +next_year+ return a date with the same day/month in the last or next year:
<ruby>
d = Date.new(2010, 5, 8) # => Sat, 08 May 2010
d.last_year # => Fri, 08 May 2009
d.next_year # => Sun, 08 May 2011
</ruby>
If date is the 29th of February of a leap year, you obtain the 28th:
<ruby>
d = Date.new(2000, 2, 29) # => Tue, 29 Feb 2000
d.last_year # => Sun, 28 Feb 1999
d.next_year # => Wed, 28 Feb 2001
</ruby>
h6. +last_month+, +next_month+
The methods +last_month+ and +next_month+ return the date with the same day in the last or next month:
<ruby>
d = Date.new(2010, 5, 8) # => Sat, 08 May 2010
d.last_month # => Thu, 08 Apr 2010
d.next_month # => Tue, 08 Jun 2010
</ruby>
If such a day does not exist, the last day of the corresponding month is returned:
<ruby>
Date.new(2000, 5, 31).last_month # => Sun, 30 Apr 2000
Date.new(2000, 3, 31).last_month # => Tue, 29 Feb 2000
Date.new(2000, 5, 31).next_month # => Fri, 30 Jun 2000
Date.new(2000, 1, 31).next_month # => Tue, 29 Feb 2000
</ruby>
h6. +beginning_of_week+, +end_of_week+
The methods +beginning_of_week+ and +end_of_week+ return the dates for the beginning and end of week, assuming weeks start on Monday:
<ruby>
d = Date.new(2010, 5, 8) # => Sat, 08 May 2010
d.beginning_of_week # => Mon, 03 May 2010
d.end_of_week # => Sun, 09 May 2010
</ruby>
+beginning_of_week+ is aliased to +monday+ and +at_beginning_of_week+. +end_of_week+ is aliased to +sunday+ and +at_end_of_week+.
h6. +next_week+
+next_week+ receives a symbol with a day name in English (in lowercase, default is +:monday+) and it returns the date corresponding to that day in the next week:
<ruby>
d = Date.new(2010, 5, 9) # => Sun, 09 May 2010
d.next_week # => Mon, 10 May 2010
d.next_week(:saturday) # => Sat, 15 May 2010
</ruby>
h6. +beginning_of_month+, +end_of_month+
The methods +beginning_of_month+ and +end_of_month+ return the dates for the beginning and end of the month:
<ruby>
d = Date.new(2010, 5, 9) # => Sun, 09 May 2010
d.beginning_of_month # => Sat, 01 May 2010
d.end_of_month # => Mon, 31 May 2010
</ruby>
+beginning_of_month+ is aliased to +at_beginning_of_month+, and +end_of_month+ is aliased to +at_end_of_month+.
h6. +beginning_of_quarter+, +end_of_quarter+
The methods +beginning_of_quarter+ and +end_of_quarter+ return the dates for the beginning and end of the quarter of the receiver's calendar year:
<ruby>
d = Date.new(2010, 5, 9) # => Sun, 09 May 2010
d.beginning_of_quarter # => Thu, 01 Apr 2010
d.end_of_quarter # => Wed, 30 Jun 2010
</ruby>
+beginning_of_quarter+ is aliased to +at_beginning_of_quarter+, and +end_of_quarter+ is aliased to +at_end_of_quarter+.
h6. +beginning_of_year+, +end_of_year+
The methods +beginning_of_year+ and +end_of_year+ return the dates for the beginning and end of the year:
<ruby>
d = Date.new(2010, 5, 9) # => Sun, 09 May 2010
d.beginning_of_year # => Fri, 01 Jan 2010
d.end_of_year # => Fri, 31 Dec 2010
</ruby>
+beginning_of_year+ is aliased to +at_beginning_of_year+, and +end_of_year+ is aliased to +at_end_of_year+.
h4. Conversions
h3. Extensions to +DateTime+
...
NOTE TO SELF: Since +DateTime+ is a subclass of +Date+, you get inherited methods that return +DateTime+ objects.
h3. Extensions to +Time+

View File

@@ -16,6 +16,9 @@ h3. Guide Assumptions
This guide is designed for beginners who want to get started with a Rails application from scratch. It does not assume that you have any prior experience with Rails. However, to get the most out of it, you need to have some prerequisites installed:
* The "Ruby":http://www.ruby-lang.org/en/downloads language version 1.8.7 or higher
TIP: Note that Ruby 1.8.7 p248 and p249 has marshaling bugs that crash Rails 3.0.0. Ruby 1.9.1 outright segfaults on Rails 3.0.0, so if you want to use Rails 3 with 1.9.x, jump on 1.9.2 trunk for smooth sailing.
* The "RubyGems":http://rubyforge.org/frs/?group_id=126 packaging system
* A working installation of the "SQLite3 Database":http://www.sqlite.org

View File

@@ -82,9 +82,13 @@ On databases that support transactions with statements that change the schema (s
h4. What's in a Name
Migrations are stored in files in +db/migrate+, one for each migration class. The name of the file is of the form +YYYYMMDDHHMMSS_create_products.rb+, that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration. The migration class' name must match (the camelcased version of) the latter part of the file name. For example +20080906120000_create_products.rb+ should define +CreateProducts+ and +20080906120001_add_details_to_products.rb+ should define +AddDetailsToProducts+. If you do feel the need to change the file name then you <em>have to</em> update the name of the class inside or Rails will complain about a missing class.
Migrations are stored in files in +db/migrate+, one for each migration class. The name of the file is of the form +YYYYMMDDHHMMSS_create_products.rb+, that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration. The name of the migration class (CamelCased version) should match the latter part of the file name. For example +20080906120000_create_products.rb+ should define +CreateProducts+ and +20080906120001_add_details_to_products.rb+ should define +AddDetailsToProducts+. If you do feel the need to change the file name then you <em>have to</em> update the name of the class inside or Rails will complain about a missing class.
Internally Rails only uses the migration's number (the timestamp) to identify them. Prior to Rails 2.1 the migration number started at 1 and was incremented each time a migration was generated. With multiple developers it was easy for these to clash requiring you to rollback migrations and renumber them. With Rails 2.1 this is largely avoided by using the creation time of the migration to identify them. You can revert to the old numbering scheme by setting +config.active_record.timestamped_migrations+ to +false+ in +config/environment.rb+.
Internally Rails only uses the migration's number (the timestamp) to identify them. Prior to Rails 2.1 the migration number started at 1 and was incremented each time a migration was generated. With multiple developers it was easy for these to clash requiring you to rollback migrations and renumber them. With Rails 2.1 this is largely avoided by using the creation time of the migration to identify them. You can revert to the old numbering scheme by adding the following line to +config/application.rb+.
<ruby>
config.active_record.timestamped_migrations = false
</ruby>
The combination of timestamps and recording which migrations have been run allows Rails to handle common situations that occur with multiple developers.