Rails - Jan 2006 - Migration db_schema_import always fails.

I have not been able to get DB migrations to work at all in Rails 1.0
for me. On multiple platforms I continually get the same errors. It
took me awhile to figure out some initial things, such as Migrations
don''t seem to support Enum column types, and doesn''t really
support
Foreign key relationships (the constraints at least). After changing
my DB schema to jive more with the migrations engine, I now get the
following error.

undefined method `string_to_binary'' for
ActiveRecord::ConnectionAdapters::ColumnDefinition:Class

This happens for me on Windows, Linux, MacOX, ruby 1.8.2/1.8.4, rails
1.0, mySQL 4.1.14.

looking at the error, it looks like there might be some sort of bug
with a backtick/single-quote mismatch.
Migration db_schema_import always fails.
Anybody else experiencing this?

--
Sean Wolfe
master nerd of
i heart squares, Co.

3711 N. Ravenswood Ave. #147 Chicago, IL 60613
Ph. (773) 531-6301  Fx. (773) 529-7041
http://www.iheartsquares.com

why don''t you post a migration file that doesn''t work?  are
you saying
db_schema_import doesn''t work?  migration doesn''t work?  both?

Sean Wolfe wrote:
>I have not been able to get DB migrations to work at all in Rails 1.0
>for me. On multiple platforms I continually get the same errors. It
>took me awhile to figure out some initial things, such as Migrations
>don''t seem to support Enum column types, and doesn''t
really support
>Foreign key relationships (the constraints at least). After changing
>my DB schema to jive more with the migrations engine, I now get the
>following error.
>
>undefined method `string_to_binary'' for
>ActiveRecord::ConnectionAdapters::ColumnDefinition:Class
>
>This happens for me on Windows, Linux, MacOX, ruby 1.8.2/1.8.4, rails
>1.0, mySQL 4.1.14.
>
>looking at the error, it looks like there might be some sort of bug
>with a backtick/single-quote mismatch.
>Migration db_schema_import always fails.
>Anybody else experiencing this?
>
>--
>Sean Wolfe
>master nerd of
>i heart squares, Co.
>
>3711 N. Ravenswood Ave. #147 Chicago, IL 60613
>Ph. (773) 531-6301  Fx. (773) 529-7041
>http://www.iheartsquares.com
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>  
>

Hello,

I just apt-get''d rails, and am running WEBrick...
I''m trying out the LAMP tutorial listed off the rails doc page...
I''ve script/generate''d the suggested MyTest
however I can''t get the urls to pull up the expected pages...
like if I goto localhost:3000/garbage it just displays a blank page,
this also happens when I goto localhost:3000/MyTest, or My_Test...
or any other gibberish that I type in.

any idea what could be going wrong?

if this is bizarre, could this problem unique to the debian unstable 
package?
if so... we should try to fix this, or at least include some 
documentation on how
to get rails going in the README.Debian file

ben

I believe migrations were not included in 1.0, but are in the trunk
scheduled for 1.1. You can use the ''rake freeze_edge'' command
to grab
the rails api updates. Try "rake -T" for details.

It''s worth noting that if you put Rails in your app''s
''vendor''
directory, it will use that copy, and you can still have a gem version
as a default for other apps.

On 1/1/06, Sean Wolfe <sean@iheartsquares.com>
wrote:
> I have not been able to get DB migrations to work at all in Rails 1.0
> for me.

On Jan 4, 2006, at 3:15 PM, Michael Yacavone wrote:
> I believe migrations were not included in 1.0, but are in the trunk
> scheduled for 1.1. You can use the ''rake freeze_edge''
command to grab
> the rails api updates. Try "rake -T" for details.
>
> It''s worth noting that if you put Rails in your app''s
''vendor''
> directory, it will use that copy, and you can still have a gem version
> as a default for other apps.
>
> On 1/1/06, Sean Wolfe <sean@iheartsquares.com> wrote:
>> I have not been able to get DB migrations to work at all in Rails 1.0
>> for me.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

	Migrations have been in rails since before 1.0 for certain and are  
definitely in rails 1.0 I use them heavily. Here are a few blog posts  
on getting started with migrations:

http://jamis.jamisbuck.org/articles/2005/09/27/getting-started-with- 
activerecord-migrations
http://glu.ttono.us/articles/2005/10/27/the-joy-of-migrations

Cheers-
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com

In checking the docs, I see I was wrong! Sorry for the confusion.
>  Migrations have been in rails since before 1.0

On 1/4/06, Mike Harris <GENIE@prodigy.net> wrote:
> why don''t you post a migration file that doesn''t work? 
are you saying
> db_schema_import doesn''t work?  migration doesn''t work? 
both?

Here''s steps as to what happens. I have a MySQL database, I created
the database originally using a db/create.sql script. Then after the
Database is generated and tested, i then run the following command:
> rake db_schema_dump
This creates the file db/schema.rb. I had to massage my SQL database
in order for the dump to work. First off, it doesn''t seem to support
ENUM datatypes. Secondly, it doesn''t seem to support foreign key
constraints (actually it halfway does, it''s able to create the
necessary indexes, but the key constraints don''t exist, also rake
doesn''t seem to be able to follow the chain of dependencies in
creating and deleting tables that have constraints.). Now i then try
and run the following command afterward:
> rake db_schema_import
Which then rewards me with the error:

undefined method `string_to_binary'' for
ActiveRecord::ConnectionAdapters::ColumnDefinition:Class

I haven''t tried any migrations yet, because I haven''t been
able to get
past this step. I''d really like to use this feature for deployment on
my servers, instead of having to write SQL patch scripts every time I
make a change. I''ll include my SQL script and the following generated
schema.rb file.
Let me know if you get any idea why this fails...


--
Sean Wolfe
master nerd of
i heart squares, Co.

3711 N. Ravenswood Ave. #147 Chicago, IL 60613
Ph. (773) 531-6301  Fx. (773) 529-7041
http://www.iheartsquares.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: db_files.tgz
Type: application/x-gzip
Size: 3203 bytes
Desc: not available
Url :
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060105/a83bc31d/db_files-0001.bin

No one has a take on this problem? Can anyone confirm the same results?

On 1/5/06, Sean Wolfe <sean@iheartsquares.com>
wrote:
> On 1/4/06, Mike Harris <GENIE@prodigy.net> wrote:
> > why don''t you post a migration file that doesn''t
work?  are you saying
> > db_schema_import doesn''t work?  migration doesn''t
work?  both?
>
>
> Here''s steps as to what happens. I have a MySQL database, I
created
> the database originally using a db/create.sql script. Then after the
> Database is generated and tested, i then run the following command:
>
> > rake db_schema_dump
>
> This creates the file db/schema.rb. I had to massage my SQL database
> in order for the dump to work. First off, it doesn''t seem to
support
> ENUM datatypes. Secondly, it doesn''t seem to support foreign key
> constraints (actually it halfway does, it''s able to create the
> necessary indexes, but the key constraints don''t exist, also rake
> doesn''t seem to be able to follow the chain of dependencies in
> creating and deleting tables that have constraints.). Now i then try
> and run the following command afterward:
>
> > rake db_schema_import
>
> Which then rewards me with the error:
>
> undefined method `string_to_binary'' for
> ActiveRecord::ConnectionAdapters::ColumnDefinition:Class
>
> I haven''t tried any migrations yet, because I haven''t
been able to get
> past this step. I''d really like to use this feature for deployment
on
> my servers, instead of having to write SQL patch scripts every time I
> make a change. I''ll include my SQL script and the following
generated
> schema.rb file.
> Let me know if you get any idea why this fails...
>
--
Sean Wolfe
master nerd of
i heart squares, Co.

3711 N. Ravenswood Ave. #147 Chicago, IL 60613
Ph. (773) 531-6301  Fx. (773) 529-7041
http://www.iheartsquares.com

Sean Wolfe <sean@...> writes:
> 
> No one has a take on this problem? Can anyone confirm the same results?
Sean,

I get the same result.   It looks like a bug to me.

Change line 85 of schema.rb to

   t.column "image_data", :binary,  :null => false

instead of

   t.column "image_data", :binary, :default => "", :null
=> false

db_schema_import then runs without error.

The not null constraint appears to be causing a default setting to be added,
even though your original create sql does not contain a default setting
(create2.sql, line 118).

I''d search around for the bug on Trac and if you can''t find a
similar bug,
submit a new one.

-damon
http://damonclinkscales.com/

I have found this bug too, and there has been a "hard-coded" fix
provided on this list.
To fix this error you need to copy the method "string_to_binary" from
the columns class and place it into the "ColumnDefinition" class.

Additionally, the migration will ignore your :size=>1.5 megabytes
options if you add it to your base schema. I got around this by adding
it to a later schema, (though the shema.rb file will still be wrong,
which makes testing a joy). I have not figured out how to fix this
problem yet.

here is where i inserted the missing method, i would like to put this
a plug in but I cannot seem to get the plug-ins working either (but
that is another problem :-) .

class ColumnDefinition < Struct.new(:base, :name, :type, :limit,
:default, :null) #:nodoc:
     def to_sql
       column_sql = "#{base.quote_column_name(name)}
#{type_to_sql(type.to_sym, limit)}"
       add_column_options!(column_sql, :null => null, :default => default)
       column_sql
     end

     #--- MISSING METHOD-----
     # added to fix missing method error when running rake tests
     # Used to convert from Strings to BLOBs
     def self.string_to_binary(value)
       value
     end




On 1/11/06, Damon Clinkscales <scales@pobox.com>
wrote:
> Sean Wolfe <sean@...> writes:
>
> >
> > No one has a take on this problem? Can anyone confirm the same
results?
> Sean,
>
> I get the same result.   It looks like a bug to me.
>
> Change line 85 of schema.rb to
>
>    t.column "image_data", :binary,  :null => false
>
> instead of
>
>    t.column "image_data", :binary, :default => "",
:null => false
>
> db_schema_import then runs without error.
>
> The not null constraint appears to be causing a default setting to be
added,
> even though your original create sql does not contain a default setting
> (create2.sql, line 118).
>
> I''d search around for the bug on Trac and if you can''t
find a similar bug,
> submit a new one.
>
> -damon
> http://damonclinkscales.com/
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
--------------------------------------------------------------------
I am Mark Daggett and I approve this message.

M Daggett wrote:
> I have found this bug too, and there has been a "hard-coded" fix
> provided on this list.
> To fix this error you need to copy the method "string_to_binary"
from
> the columns class and place it into the "ColumnDefinition" class.
> 
Good to know.


The addition by the schema dumper of :default => "" on a :binary
column
also seems like a bug to me.  The create sql doesn''t specify a default 
and there are two other blobs in the same table definition, that did not 
get that default.  It''s a mystery.

Here''s his table definition:

CREATE TABLE images (
  id BIGINT unsigned NOT NULL auto_increment,
  original_filename varchar(255) NOT NULL,
  image_data blob NOT NULL,
  content_type varchar(100) default NULL,
  big_thumb blob,
  small_thumb blob,
  title varchar(255) UNICODE default NULL,
  original_x SMALLINT default NULL,
  original_y SMALLINT default NULL,
  thum_x SMALLINT default NULL,
  thum_y SMALLINT default NULL,
  small_thum_x SMALLINT default NULL,
  small_thum_y SMALLINT default NULL,
  PRIMARY KEY  (id)
) ENGINE=InnoDB;

I am guessing it is because of the NOT NULL constraint, since that is 
the only difference.

-damon
http://damonclinkscales.com/

-- 
Posted via http://www.ruby-forum.com/.

On 1/11/06, Damon Clinkscales <scales@pobox.com>
wrote:
> I am guessing it is because of the NOT NULL constraint, since that is
> the only difference.
Ahh i see... It seems like the Migration code has lots of trouble with
constraints. It doesn''t like :
CONTRAINT fk_article_images FORIEGN KEY (image_id) REFERENCES images(id)

 I''ll take a look at the fixes offered here.

Thanks.

--
Sean Wolfe
master nerd of
i heart squares, Co.

3711 N. Ravenswood Ave. #147 Chicago, IL 60613
Ph. (773) 531-6301  Fx. (773) 529-7041
http://www.iheartsquares.com