-
Notifications
You must be signed in to change notification settings - Fork 609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prefer SQL column type over normalized AR type #231
Conversation
A small change but with big impact. I'm not sure how other would like this. |
I think that people will like more correct annotations. |
I'm intrigued. How is a point specified in an AR schema or migration?
As a compromise, we could add the sql_type in parens if it's different from
the AR type.
|
What I meant is I don't know much this will change over the existing annotations. @alexch's suggestion make sense if you don't mind making that change. |
I tested it on Rails 4.2.1 now. rails new maps -d postgresql -T
cd maps
rails g model marker name location:point class CreateMarkers < ActiveRecord::Migration
def change
create_table :markers do |t|
t.string :name
t.point :location
t.timestamps null: false
end
end
end rake db:create db:migrate
pgcli maps_development
# ...
ActiveRecord::Schema.define(version: 20150412093810) do
# These are extensions that must be enabled in order to support this database
enable_extension "plpgsql"
create_table "markers", force: :cascade do |t|
t.string "name"
t.point "location"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
end I think that the proposed change will not cause much trouble in people's model annotations. First of all, not many people use those exotic types :) And if they do, and their |
Prefer SQL column type over normalized AR type
Thank you. |
We have columns of type
point
in our PostgreSQL database:http://www.postgresql.org/docs/9.4/interactive/datatype-geometric.html
They are annotated as
string
in our models. This is misleading:point
is actually 2 floats; not even close to a string.I thought that SQL type should take precedence.
I understand that this change may be not enough or is completely wrong, and would welcome suggestions on the best solution.