2011-06-06 14:17:44 -04:00
|
|
|
require "cases/helper"
|
2008-07-14 11:12:54 -04:00
|
|
|
|
2011-01-31 17:38:20 -05:00
|
|
|
module ActiveRecord
|
|
|
|
module ConnectionAdapters
|
|
|
|
class ColumnDefinitionTest < ActiveRecord::TestCase
|
|
|
|
def setup
|
|
|
|
@adapter = AbstractAdapter.new(nil)
|
|
|
|
def @adapter.native_database_types
|
2016-08-16 03:30:11 -04:00
|
|
|
{ string: "varchar" }
|
2011-01-31 17:38:20 -05:00
|
|
|
end
|
2013-03-15 22:22:07 -04:00
|
|
|
@viz = @adapter.schema_creation
|
2011-01-31 17:38:20 -05:00
|
|
|
end
|
2009-08-09 23:43:56 -04:00
|
|
|
|
2011-01-31 17:38:20 -05:00
|
|
|
# Avoid column definitions in create table statements like:
|
|
|
|
# `title` varchar(255) DEFAULT NULL
|
|
|
|
def test_should_not_include_default_clause_when_default_is_null
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
column = Column.new("title", nil, SqlTypeMetadata.new(limit: 20))
|
2011-01-31 17:38:20 -05:00
|
|
|
column_def = ColumnDefinition.new(
|
2013-03-15 22:34:20 -04:00
|
|
|
column.name, "string",
|
2011-01-31 17:38:20 -05:00
|
|
|
column.limit, column.precision, column.scale, column.default, column.null)
|
2016-08-06 13:55:02 -04:00
|
|
|
assert_equal "title varchar(20)", @viz.accept(column_def)
|
2011-01-31 17:38:20 -05:00
|
|
|
end
|
2009-08-09 23:43:56 -04:00
|
|
|
|
2011-01-31 17:38:20 -05:00
|
|
|
def test_should_include_default_clause_when_default_is_present
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
column = Column.new("title", "Hello", SqlTypeMetadata.new(limit: 20))
|
2011-01-31 17:38:20 -05:00
|
|
|
column_def = ColumnDefinition.new(
|
2013-03-15 22:34:20 -04:00
|
|
|
column.name, "string",
|
2011-01-31 17:38:20 -05:00
|
|
|
column.limit, column.precision, column.scale, column.default, column.null)
|
2016-08-06 14:20:22 -04:00
|
|
|
assert_equal "title varchar(20) DEFAULT 'Hello'", @viz.accept(column_def)
|
2009-08-09 23:43:56 -04:00
|
|
|
end
|
|
|
|
|
2011-01-31 17:38:20 -05:00
|
|
|
def test_should_specify_not_null_if_null_option_is_false
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
type_metadata = SqlTypeMetadata.new(limit: 20)
|
|
|
|
column = Column.new("title", "Hello", type_metadata, false)
|
2011-01-31 17:38:20 -05:00
|
|
|
column_def = ColumnDefinition.new(
|
2013-03-15 22:34:20 -04:00
|
|
|
column.name, "string",
|
2011-01-31 17:38:20 -05:00
|
|
|
column.limit, column.precision, column.scale, column.default, column.null)
|
2016-08-06 14:20:22 -04:00
|
|
|
assert_equal "title varchar(20) DEFAULT 'Hello' NOT NULL", @viz.accept(column_def)
|
2009-08-09 23:43:56 -04:00
|
|
|
end
|
|
|
|
|
2015-12-15 17:01:30 -05:00
|
|
|
if current_adapter?(:Mysql2Adapter)
|
2011-01-31 17:38:20 -05:00
|
|
|
def test_should_set_default_for_mysql_binary_data_types
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
type = SqlTypeMetadata.new(type: :binary, sql_type: "binary(1)")
|
2016-01-10 14:54:03 -05:00
|
|
|
binary_column = MySQL::Column.new("title", "a", type)
|
2011-01-31 17:38:20 -05:00
|
|
|
assert_equal "a", binary_column.default
|
2009-08-09 23:43:56 -04:00
|
|
|
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
type = SqlTypeMetadata.new(type: :binary, sql_type: "varbinary")
|
2016-01-10 14:54:03 -05:00
|
|
|
varbinary_column = MySQL::Column.new("title", "a", type)
|
2011-01-31 17:38:20 -05:00
|
|
|
assert_equal "a", varbinary_column.default
|
|
|
|
end
|
2009-08-09 23:43:56 -04:00
|
|
|
|
2015-12-24 09:05:17 -05:00
|
|
|
def test_should_be_empty_string_default_for_mysql_binary_data_types
|
|
|
|
type = SqlTypeMetadata.new(type: :binary, sql_type: "binary(1)")
|
2016-01-10 14:54:03 -05:00
|
|
|
binary_column = MySQL::Column.new("title", "", type, false)
|
2015-12-24 09:05:17 -05:00
|
|
|
assert_equal "", binary_column.default
|
|
|
|
|
|
|
|
type = SqlTypeMetadata.new(type: :binary, sql_type: "varbinary")
|
2016-01-10 14:54:03 -05:00
|
|
|
varbinary_column = MySQL::Column.new("title", "", type, false)
|
2015-12-24 09:05:17 -05:00
|
|
|
assert_equal "", varbinary_column.default
|
|
|
|
end
|
|
|
|
|
2011-01-31 17:38:20 -05:00
|
|
|
def test_should_not_set_default_for_blob_and_text_data_types
|
2016-01-10 15:03:31 -05:00
|
|
|
text_type = MySQL::TypeMetadata.new(
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
SqlTypeMetadata.new(type: :text))
|
2010-03-31 17:05:34 -04:00
|
|
|
|
2016-01-10 14:54:03 -05:00
|
|
|
text_column = MySQL::Column.new("title", nil, text_type)
|
2011-01-31 17:38:20 -05:00
|
|
|
assert_equal nil, text_column.default
|
2010-08-02 04:37:57 -04:00
|
|
|
|
2016-01-10 14:54:03 -05:00
|
|
|
not_null_text_column = MySQL::Column.new("title", nil, text_type, false)
|
2011-01-31 17:38:20 -05:00
|
|
|
assert_equal "", not_null_text_column.default
|
|
|
|
end
|
2010-08-02 04:37:57 -04:00
|
|
|
|
2014-02-05 03:51:34 -05:00
|
|
|
def test_has_default_should_return_false_for_blob_and_text_data_types
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
binary_type = SqlTypeMetadata.new(sql_type: "blob")
|
2016-01-10 14:54:03 -05:00
|
|
|
blob_column = MySQL::Column.new("title", nil, binary_type)
|
2011-01-31 17:38:20 -05:00
|
|
|
assert !blob_column.has_default?
|
2010-08-02 04:37:57 -04:00
|
|
|
|
rm `Column#cast_type`
The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.
During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.
As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API
Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.
The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.
2015-02-03 12:06:10 -05:00
|
|
|
text_type = SqlTypeMetadata.new(type: :text)
|
2016-01-10 14:54:03 -05:00
|
|
|
text_column = MySQL::Column.new("title", nil, text_type)
|
2011-01-31 17:38:20 -05:00
|
|
|
assert !text_column.has_default?
|
|
|
|
end
|
2010-08-02 04:37:57 -04:00
|
|
|
end
|
2010-03-31 17:05:34 -04:00
|
|
|
end
|
|
|
|
end
|
2008-08-23 12:51:09 -04:00
|
|
|
end
|