search for: schema_format

Hi. I''ve not seen anything on this so thought I''d put forward the idea and see if it has any merit, or is already in practice. When using migrations with config.active_record.schema_format = :ruby (ruby as the canonical DB definition) it seems there would be no need to query the database itself to determine its structure; it would already be known. This might have some good implications for database performance, reducing the number of queries which need to be executed. Has this been...

...g this: 1) createdb myapp_test 2) rake db:test:clone_structure 3) rake test:units rake aborted! PGError: ERROR: relation "matches" already exists I''m using the :sql schema format because there are some problems with postgres and the :ruby schema format config.active_record.schema_format = :sql It seems rake test:units is trying to create the tables again, is this a bug? Jeroen

In development and production, I''ve got postgresql constraints that prevent deleting a CaseManager if there is a Client that belongs to that CaseManager. In unit tests...and obviously in my testing db, those restrictions don''t get added. Is it wrong to test for deleting dependent records in unit tests? Craig --~--~---------~--~----~------------~-------~--~----~ You received

...rations, perform all the tsearch2 related stuff for the table that requires full text indexing. This includes loading tsearch2.sql (and uninstall_tsearch2.sql in the down part), creating the tsvector column, the index on it, and the trigger that updates the tsvector column. 2) config.active_record.schema_format = :sql in the environment since schemas would puke at the tsvector column. 3) Copy all the inserts from the tsearch2.sql file and add it to a separate file. Setting schema_format to sql will only have the table structure copied to the test database, not the actual content of the pg_* tables which...

I haven''t seen anyone mention this yet. The tail end of the migration process is a call to schema.dump. Our primary keys are uuids and these choke schema.dump on both oracle and postgres. The latter fails silently (skips three tables) while the former complains about the RAW(16) in each of the three tables. Anyone had a similar experience? -- Posted via http://www.ruby-forum.com/.

Hi, In my environment.rb, I have set: config.active_record.schema_format = :ruby Whenever I do a rake db:migrate, both db/development_structure.sql and db/schema.rb get generated. This shouldn''t happen should it? I thought I should only get db/schema.rb? Thanks, Jordan

Is there a way to specify not not use schema.rb but instead using a native sql file to clone structure to the test db? Schema.rb doesn''t really work that well for mediumblobs ... Thanks. -- Posted via http://www.ruby-forum.com/.

...index "emcolumn", ["upper(name)"], :name => "ind_emcolumn_uname" The created schema.rb file contains: add_index "emcolumn", ["sys_nc00013$"], :name => "ind_emcolumn_uname" Well, we are aware we can use "config.active_record.schema_format = :sql" to fall back to a SQL file containing only table definition statements. However it would be nice if the Oracle adapter would understand such constructs. A possible solution for this problem is attached as patch against Rails 1.2 RC1. I''m quite sure it''s not perfe...

Sans rails my normal approach to handling this would be to enforce it in the database and when a database operation failed I''d try to validate the model to produce an error message. It''s always served me pretty well. Rails expects you to validate before commiting but of course this does nothing to guarantee referential integrity. It''s perfectly possible for one

Hi, I''d like to use migrations to build my initial database. Is there a gem or plugin that will generate the migration code for initial db if I point it at a live database or sql file? If yes, then can you automatically generate the incremental migrations as well? Thanks, Jason

Hi Folks, There is much discussion where I work at present regarding migrations, and the ''correct'' usage or not of them. TL;DR Should migrations be used just to modify schema, and other ''deploy'' tasks done other ways? If yes, how to ensure no repeat runs of such tasks (seeds, jobs etc) Background Once you''re live there are often additional things

So after successfully getting the test SQLite db to run from memory, I tried running some tests but found that somewhere in the schema translation from Postgres (my devel database) and SQLite Rails fails to properly set the ''id'' column, which breaks all kinds of things. Take as an example my ''users'' table. In Postgres the schema is (generated with pgAdmin III):

I just got a new PC at work. My project files were copied from my old drive. Just to be sure, though, I have erased them and pulled them back down from source control. My development database server is MySQL My test database server is sqlite3 I am having a confusing issue: tests are failing and errors are happening that weren''t happening before. Furthermore, they aren''t

Hi! I got a class named EinsatzFilter which I serialized to session. Before saving to session it works afterwards I keep getting the message: "undefined method `to_s'' for #<Person:0x38c6ab8>". "Person" is a from ActiveRecord::Base inherited class. Code: class EinsatzFilter include ApplicationHelper attr_reader :personen, :monat, :projekte, :kunde

I recently started using migrations to create the schema of a Rails project I am working on. The database I am using for this project is MySQL. The initial migration creates the table and also includes a number of execute statements (to do some things like setting primary keys, autoincrement on some columns and other messy voodoo). Running "rake migrate" creates the database with no

I''m somewhat of a newbie - played with recent versions of rails a few mths ago, but have decided to start from scratch with 1.0. I want to build my new db as much as possible with migrations, so I watched DHH''s migrations movie from rubyonrails.org. A few things confuse me: 1. He generates the model ("post") before running rake db_schema_dump. Is that necessary or

Hi. I''m having a problem with my testing. The following table in my development database (MySQL 4.1.12, InnoDB): +-----------------------+------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------------------+------------------------+------+-----+---------+----------------+ |

I''ve been working through the AWDWR book (both hard copy first edition and "beta book" pdf of second and I''m running into some problems when running unit tests. Integration tests and functional tests are behaving correctly and are operating against the test database. However unit tests try to operate against the development database and fail. (ie rake test:unit

....sql, Rake will use schema.rb. That''s portable and good stuff overall but there is a slight compatibility issue. Ruby schema doesn''t know how to do FULLTEXT index syntax for MySQL. To work around it, you can either write migration and execute SQL, or put: config.active_record.schema_format = :sql in your environment.rb to stick with SQL schema format. Don''t put anything in schema.rb manually, it will get overwritten. See [http://dev.rubyonrails.org/ticket/4474] for bug tracking reference. -- Posted via http://www.ruby-forum.com/.

..._on` datetime default NULL, `recipients_count` int(11) default ''0'', PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 ... In test I still see "InnoDB"... Deleting the schema.rb didn''t help. environment.rb contains this: config.active_record.schema_format = :ruby test.rb doesn''t seem to contain anything that overrides that. I am also wondering when the migration for test occurs? After rake migrate nothing seems to happen to the test database, but while running my tests with rake it seems to also do the migration. Am I doing something...