schemaplus / schema_plus Goto Github PK

View Code? Open in Web Editor NEW

683.0 683.0 86.0 1.42 MB

SchemaPlus provides a collection of enhancements and extensions to ActiveRecord

License: Other

Ruby 100.00%

schema_plus's People

Contributors

Stargazers

Watchers

schema_plus's Issues

get 100% code coverage

rspec should give us 100% code coverage. it's pretty good now, about half the code at 100% and most everything else above 90%. but would be good to go all the way before releasing.

Forcing the creating of views if they already exist

When I re-load the schema I get an error loading the views:

Table 'my_view' already exists: CREATE VIEW...

Rails migrations usually solve this problem for tables by forcing the table creation (i.e :force => true). Does something like this exist in schema_plus for views? Can it be added?

Pull in the generators from automatic_foreign_key.

stack level to deep error

I got this error when I run rake db:migrate

$ rake --trace db:migrate                                                                                       
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:migrate
** Invoke db:schema:dump (first_time)
** Invoke db:load_config 
** Execute db:schema:dump
rake aborted!
stack level too deep
/Users/user/.rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/rake-0.9.2/lib/rake/task.rb:162
Tasks: TOP => db:schema:dump

After I remove schema_plus from my Gemfile the same command run just fine and coming back if I add schema_plus in the Gemfile again. The migration file was just a basic user table use by Devise and nothing more.

associations: fix method overriding logic and add spec tests

auto associations shouldn't override existing methods. add spec test for this.

the exception is that it will override :type, but it should only do so for Object#type which is deprecated anyway. currently it always overrides type. fix that and add a spec test.

feature request: expose table dependency ordering

schema_plus internally uses tsort to order the tables based on foreign key constraints, for clean dumping in the schema.rb

it would be nice to expose that in some clean way, for cases when the client wants to traverse the tables in dependency order. (e.g. for data export or import).

maybe something like connection.ordered_tables yielding a list (with some options on how to deal with cycles)

log or manifest of (auto) created things

For debugging, would be handy to easily see "what associations/validations got created?".
Also, especially for somebody new to this gem, it would be very comforting to be able to know what got created. Associations I suppose you'd find out soon enough when you try to access them, but for validations you just need faith (or do your own spec tests; but you shouldn't have to test every gem you use...). Maybe same for automatic foreign keys and indexes, but those are easy enough to find out via database inspection tools.

So I propose that active_schema report on the things it creates, especially those created implicitly. The question is how...

Via logger.info ? That's the easiest, though it means having to wade through log output in order to find.
In some explicit manifest file? If so, that raises questions such as: what's the file named? what directory is it in? one file per model or one for the whole app? text or rdoc or html or ...?
As comments in the model source? Like the 'annotate' gem (see issue #12).

Of course it should be configurable (do any/all the above?) and perhaps depend on RAILS_ENVIRONMENT etc.

BTW if we do this, it may make sense to report not just the things implicitly created by active_schema, but the complete list of created things: column accessors implicitly created by AR, the user's expclitly created associations and composed_of accessors, etc. I.e. put all the info in a single place for easy reference. (in which case this feature would be subsuming the 'annotate' gem.)

thoughts...?

Allow to restrict validations by type

valdiations.except_type => [:length]

validations.only_type => [:presence, :uniqueness]

"rake spec" should always run all adapters rather than abort when one adapter fails

Easy fix, just set spec.fail_on_error = false.

(I hope you're OK with this new behavior. Can still run a single adapter via "rake postgresql:spec" etc., but now can add a failing test and more easily make sure it fails everywhere.)

Schema dump group views at end?

First of all, thanks for your work bringing forward redhill's fantastic library supporting views and foreign keys. Discovered you during a recent 3.0=>3.1 upgrade.

This is really more a question/feature request than a bug.

We leverage views heavily in our Rails app, and redhill's approach of grouping all views at end of the schema.rb was quite helpful in development and refactoring.

Currently views are intermixed with tables in the schema dump.

Would you be averse to a pull request that grouped the views at the end as was the case with redhill?

No conditions method on Mysql2IndexDefinition

I can't execute migration.

==  AddUniqueIndexToConversions: migrating ====================================
-- add_index(:conversions, :name, {:unique=>true})
rake aborted!
An error has occurred, all later migrations canceled:

undefined method `conditions' for #<ActiveRecord::ConnectionAdapters::Mysql2IndexDefinition:0x00000006c5e3c8>
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/schema_plus-0.3.1/lib/schema_plus/active_record/connection_adapters/index_definition.rb:55:in `=='
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/schema_plus-0.3.1/lib/schema_plus/active_record/connection_adapters/schema_statements.rb:62:in `!='
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/schema_plus-0.3.1/lib/schema_plus/active_record/connection_adapters/schema_statements.rb:62:in `add_index_exception_handler'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/schema_plus-0.3.1/lib/schema_plus/active_record/connection_adapters/schema_statements.rb:54:in `rescue in add_index_with_schema_plus'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/schema_plus-0.3.1/lib/schema_plus/active_record/connection_adapters/schema_statements.rb:52:in `add_index_with_schema_plus'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:447:in `block in method_missing'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:422:in `block in say_with_time'
/home/lite/.rvm/rubies/ruby-1.9.3-p125-perf/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:422:in `say_with_time'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:442:in `method_missing'
/home/lite/work/newsho/db/migrate/20120322142053_add_unique_index_to_conversions.rb:11:in `up'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:394:in `block (2 levels) in migrate'
/home/lite/.rvm/rubies/ruby-1.9.3-p125-perf/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:394:in `block in migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:185:in `with_connection'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:375:in `migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:507:in `migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:687:in `block (2 levels) in migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:744:in `call'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:744:in `ddl_transaction'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:686:in `block in migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:671:in `each'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:671:in `migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:549:in `up'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/migration.rb:530:in `migrate'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/activerecord-3.1.4/lib/active_record/railties/databases.rake:161:in `block (2 levels) in <top (required)>'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
/home/lite/.rvm/rubies/ruby-1.9.3-p125-perf/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/gems/rake-0.9.2.2/bin/rake:33:in `<top (required)>'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/bin/rake:19:in `load'
/home/lite/.rvm/gems/ruby-1.9.3-p125-perf/bin/rake:19:in `<main>'
Tasks: TOP => db:migrate

There is no method 'conditions'
https://github.com/rails/rails/blob/v3.1.4/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb#L24

# Gemfile
rails '3.1.4'
mysql2 '0.3.11'

Interferes with certain rails rake tasks: Rake error "topological sort failed"

I've noticed that recently after rails 3.1 bump and switching from redhillonrails-* to schema_plus, some rake tasks (namely db:migrate) now fail. The migration itself succeeds but then it spits out:

rake aborted!
topological sort failed: ["profiles", "invitations"]

Tasks: TOP => db:schema:dump
(See full trace by running task with --trace)

and db/schema.rb is left empty. If I manually run rake db:schema:dump it works as expected.

Re-running rake db:migrate (even with no pending migrations), while passing --trace, shows where I think schema_plus may be causing this:

$ rake --trace db:migrate
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:migrate
** Invoke db:schema:dump (first_time)
** Invoke db:load_config 
** Execute db:schema:dump
rake aborted!
topological sort failed: ["profiles", "invitations"]
/opt/local/lib/ruby/1.8/tsort.rb:153:in `tsort_each'
/opt/local/lib/ruby/1.8/tsort.rb:184:in `each_strongly_connected_component'
/opt/local/lib/ruby/1.8/tsort.rb:211:in `each_strongly_connected_component_from'
/opt/local/lib/ruby/1.8/tsort.rb:220:in `each_strongly_connected_component_from'
/opt/local/lib/ruby/1.8/tsort.rb:210:in `each_strongly_connected_component_from'
/opt/local/lib/ruby/gems/1.8/gems/schema_plus-0.1.2/lib/schema_plus/active_record/schema_dumper.rb:64:in `each'
/opt/local/lib/ruby/gems/1.8/gems/schema_plus-0.1.2/lib/schema_plus/active_record/schema_dumper.rb:64:in `tsort_each_child'
/opt/local/lib/ruby/1.8/tsort.rb:204:in `each_strongly_connected_component_from'
/opt/local/lib/ruby/1.8/tsort.rb:183:in `each_strongly_connected_component'
/opt/local/lib/ruby/gems/1.8/gems/schema_plus-0.1.2/lib/schema_plus/active_record/schema_dumper.rb:55:in `each'
/opt/local/lib/ruby/gems/1.8/gems/schema_plus-0.1.2/lib/schema_plus/active_record/schema_dumper.rb:55:in `tsort_each_node'
/opt/local/lib/ruby/1.8/tsort.rb:181:in `each_strongly_connected_component'
/opt/local/lib/ruby/1.8/tsort.rb:149:in `tsort_each'
/opt/local/lib/ruby/1.8/tsort.rb:136:in `tsort'
/opt/local/lib/ruby/gems/1.8/gems/schema_plus-0.1.2/lib/schema_plus/active_record/schema_dumper.rb:45:in `tables'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-3.1.1.rc1/lib/active_record/schema_dumper.rb:27:in `dump'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-3.1.1.rc1/lib/active_record/schema_dumper.rb:21:in `dump'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-3.1.1.rc1/lib/active_record/railties/databases.rake:349
/opt/local/lib/ruby/gems/1.8/gems/activerecord-3.1.1.rc1/lib/active_record/railties/databases.rake:347:in `open'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-3.1.1.rc1/lib/active_record/railties/databases.rake:347
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `call'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
/opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-3.1.1.rc1/lib/active_record/railties/databases.rake:162
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `call'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
/opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:62:in `run'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.9.2/bin/rake:32
/opt/local/bin/rake:19:in `load'
/opt/local/bin/rake:19
Tasks: TOP => db:schema:dump

Any ideas ?

Merge in schema_valiations from latest version on github

Create configuration to enable/disable it.
Create spec tests for it.

Per-table enable/disable of auto fk and auto index

Migration::create_table could take extra options to enable/disable automatic foreign key and automatic index creation, that would override the global config.

uninitialized constant Rails::Railtie

Is schema_plus 1.0.1 already not backwards compatible with rails 2.3.x? When switching to schema_plus on a 2.3.12 app I get this:

uninitialized constant Rails::Railtie
C:/Ruby187/lib/ruby/gems/1.8/gems/activesupport-2.3.12/lib/active_support/dependencies.rb:466:in load_missing_constant' C:/Ruby187/lib/ruby/gems/1.8/gems/activesupport-2.3.12/lib/active_support/dependencies.rb:106:inconst_missing'
C:/Ruby187/lib/ruby/gems/1.8/gems/schema_plus-0.1.1/lib/schema_plus/railtie.rb:2
...

Switching back to automatic_foreign_key/redhillonrails_core fixes the problem, which is fine for me until I upgrade to rails 3, but I figured I'd file an issue since the README says backwards compatibility is likely to be broken at schema_plus 2.x.x, implying that 1.0.1 is intended to be backwards compatible.

Cheers!

Miles

needs to work with latest mysql2 gem

Mysql2 has its own TableDefinition object that isn't getting the monkey patches.

Should we get rid of t.belongs_to?

Feature Request: add_column or change_table functionality

Just as the title says: The gem works great with create_table, but I'd love to be able to get the same functionality when I add a new column to an existing table.

README should list required version of sqlite3

if you're using sqlite3, it must be version 3.7. the README should say this.

and perhaps add a debugging tip: if you get an error
SQLite3::SQLException: near "NO": syntax error: CREATE TABLE ...
that's a sign that you're not using the right version of sqlite3. make sure that you have version >= 3.7, and make sure that your installed sqlite3 gem was compiled against that version.

Sqlite3 adapter should raise "NotImplemented" exceptions on attempts to add/remove a foreign key

currently an attempt will yield a syntax error which is cryptic.
Also add a spec test for this case

Postgres: polymorphic option

I run into a problem when schema_plus try to create foreign key for references resouce even when it has polymorphic option set to true.

def self.up
     create_table :admin_notes do |t|
           t.references :resource, :polymorphic => true, :null => false
           t.references :admin_user, :polymorphic => true
           t.text :body
           t.timestamps
     end
end


PGError: ERROR:  relation "resources" does not exist
: CREATE TABLE "admin_notes" ("id" serial primary key, "resource_id" integer NOT NULL, "resource_type" character varying(255) NOT NULL, "admin_user_id" integer, "admin_user_type" character varying(255), "body" text, "created_at" timestamp, "updated_at" timestamp, FOREIGN KEY ("resource_id") REFERENCES "resources" ("id"), FOREIGN KEY ("admin_user_id") REFERENCES "admin_users" ("id"))

Check if active_schema works with jruby and rubinius

Maybe use rvm to run specs against:

MRI 1.8
MRI 1.9
JRuby
Rubinius
MacRuby (?)

rake db:test:clone doesn't clone indexes, foreign keys and views

db:rollback not remove constraint with change_column

How can i to remove a constraint using a migration rollback?

O tried this but not works:

def self.up
  change_column :mains, :another_id, :integer, :references => :anothers
end

def self.down
  change_column :mains, :another_id, :integer, :references => nil
end

This is possible?

Thanks.

Enhance output of "annotate" gem?

If the "annotate" gem is present, active_schema could potentially arrange to include automatically-generated associations and validations in the annotation output.

(I've never used "annotate" but it seems intriguing, and having annotation of the results might make automatic generation less scary to those not used to it.)

associations: add :only and :except config options

Specs cleanup

The spec tests were jammed together inelegantly to deal with the fact that they used different schemas. That could be made cleaner.

Import recent bugfixes from redhillonrails_core

FKs and indexes ordering in schema dump was fixed.

mlomnicki/redhillonrails_core#8

mlomnicki/redhillonrails_core#9

get working with rails 3.1

i tried 3.1.0.rc1 and got a bunch of failures... now need to start debugging...

specs: get model autoloading working

for auto association and schema validations it would be very nice to be able to do something like
before(:each) do
ActiveSchema::Dependencies.remove_constant Post
ActiveSchema::Dependencies.remove_constant Comment
etc.
end
and have models be loaded and redefined for each test.

Per-model enable/disable of automatic associations & validations

It should be possible to override the global settings for automatic model features, automatic associations & automatic validations.

Will need to work out decent syntax, and also decide whether those would be global to the model vs having finer-grain control on a per-column (and/or per feature type) basis.

change_column fails if index is already there

If I use change_column with a column that is already there, it fails:

PGError: ERROR:  current transaction is aborted, commands ignored until end of transaction block
:            SELECT distinct i.relname, d.indisunique, d.indkey, m.amname, t.oid, 
                    pg_get_expr(d.indpred, t.oid), pg_get_expr(d.indexprs, t.oid)
             FROM pg_class t, pg_class i, pg_index d, pg_am m
           WHERE i.relkind = 'i'
             AND i.relam = m.oid
             AND d.indexrelid = i.oid
             AND d.indisprimary = 'f'
             AND t.oid = d.indrelid
             AND t.relname = 'users'
             AND i.relnamespace IN (SELECT oid FROM pg_namespace WHERE nspname IN ('"$user"','public') )
          ORDER BY i.relname

Remove create_foreign_keys generator

not really useful. Needs a lot of manual customization
won't work for sqlite3
more confusing than helpful

associations should recognize parent_id and generate child associations

should recognize column parent_id as defaulting to referencing self
should recognize that the reverse of 'belongs_to parent' is 'has_many children' or 'has_one child' or even 'has_and_belongs_to_many children'

(could imagine having inflections-style mechanism for complementary roles
parent/child
manager/employee
etc.
with the ability to extend them in the config setup. but that may be overkill.)

Clean up README.rdoc

references doesn't create foreign keys

    t.references :user, :null => false

should create both a foreign key and an index

Sqlite3 does not support altering a table to remove foreign key constraints

It fails when I try to use change_column.

Heroku deploy fails because of schema_plus gemspec file?

After upgrading to 0.1.3 (from 0.1.2) I got this error when deploying to Heroku:

-----> Heroku receiving push
-----> Ruby/Rails app detected
-----> Installing dependencies using Bundler version 1.1.rc
       Running: bundle install --without development:test --path vendor/bundle --deployment
       Fetching gem metadata from http://rubygems.org/......
       Fetching gem metadata from http://rubygems.org/..
       Using rake (0.9.2)
       Using RedCloth (4.2.8)
       [A lot of gems]
       Installing sass-rails (3.1.4)
       Installing valuable (0.9.2)
       ArgumentError: invalid byte sequence in US-ASCII
       An error occured while installing schema_plus (0.1.3), and Bundler cannot continue.
       Make sure that `gem install schema_plus -v '0.1.3'` succeeds before bundling.
 !
 !     Failed to install gems via Bundler.
 !
 !     Heroku push rejected, failed to compile Ruby/rails app

Inspired by what @mlomnicki wrote here I tried removing non ascii characters from schema_plus' gemspec file.

That solved the problem!

I guess Heroku should work even though there are non ascii characters in the gemspec file, but you might want to consider removing them as long as this problem persists.

config: add runtime warnings for bad config use

in particular:

shouldn't be able to override enable, only set it at the global level.
if enable is false, should warn if you try to set other options (since they'll be no-ops)

these can both be handled in Config#update_attributes and/or Config#merge.

and of course need to add tests for these. (do we have a way to test :enable in rspec?)

Schema dumper should use :references

Schema dumper should use :references on columns rather than t.foreign_key, to avoid double definition when loading schema with fk.auto_create enabled.

Add a spec test for schema dumping/loading round-trip?

use alias_method_chain only once rather than chaining for each feature

to avoid runtime overhead (and general ugliness) of having long alias method chains, do something like this:

if (any runtime modules are enabled)
    include ActiveSchema::ActiveRecordChains
end

module AS:ActiveRecordChains
    alias_method_chain :new, :active_schema

    def new_with_active_schema
        load_foreign_key_associations if config.associations.enabled?
        load_schema_validations if config.validations.enabled?
        new_without_active_schema
    end
end

Merge in foreign_key_assocation from its subdirectory

Create configuration to enable/disable it.
Create spec tests for it.

associations: improvements to concise-naming

A few improvements needed:

Should be configurable to use full names rather than concise names, or to use both full and concise names
concise name should strip off shared prefixes too. e.g. widget_parts and widget_colors should refer to each other as just "parts" and "colors" in the concise version.

Create rake task which compares database constraints with model validations

The task should check if database constraints have matching validations.
It would help to detect missing validations

state varchar(10) => validate_numericality_of :state, :maximum => 10, :integer_only => true
login NOT NULL => validate_presence_of :login
active boolean => validate_inclusion_of :active, :in => [true, false]

Of course it would be usable only when schema_validations are disabled

stronger modularization

put all features and capabilities into separable modules, and only include them if a corresponding config.enable is set.

ultimate goal (may not be acheivable) is that if all enable's are false, the gem should have no effect other than defining ActiveSchema.config

create_table index things

a few things re indexes in create_table:

need to add spec examples to test t.column :foo, :index => ...args...
should define method t.index(args) that can be called inline in the table definition rather than listing the index afterwards via add_index. (strictly speaking t.index isn't necessary since any index can be defined via t.column :index, but it makes sense for completeness/consistency with foreign_key.)
schema dumper should generate t.index within the table definition rather than add_index afterwards, for compactness (and consistency with foreign_key).

[actually, instead of generating t.index and t.foreign_keys, dumper could generate t.column ... :references => ... :index, that would probably be cleanest. the code would be a little uglier to graft onto AR's dumper, but doable.]

Delete the automatic_foreign_key and redhillonrails_core subdirectories

relation "[table name]" does not exist

Tried switching from redhillonrails_core to schema_plus by recreating my db from scratch. After the second migration I got this:

PGError: ERROR:  relation "countries" does not exist
: CREATE TABLE "needs" ("id" serial primary key, "company_id" integer, "country_id" integer, "destination_id" integer, "passenger_count" integer, "created_at" timestamp, "updated_at" timestamp, FOREIGN KEY ("company_id") REFERENCES "companies" ("id"), FOREIGN KEY ("country_id") REFERENCES "countries" ("id"), FOREIGN KEY ("destination_id") REFERENCES "destinations" ("id"))

The migration method looks like this:

  def self.up
    create_table :needs do |t|
      t.references :company
      t.references :country
      t.integer :destination_id
      t.integer :passenger_count

      t.timestamps
    end

    add_index :needs, :country_id
    add_index :needs, :destination_id

  end

My best guess is, that this is because schema_plus (contrary to redhillonrails_core) is creating foreign key constraints when the user is using the t.references method. In the above example the countries table have not yet been created.

If my guess is right, can I somehow disable this so I get the behavior from redhillonrails_core?

Move postgresql specific stuff to separate gem

Conditional and expressional indexes should be moved to active_schema-postgres

use Railties for plugin

Railties is the way to do plugins in Rails 3. and i think it should make it easier to approach #22, by giving access to the right place to conditionally load modules based on overrides in the application initialization.

schemaplus / schema_plus Goto Github PK

schema_plus's People

Contributors

Stargazers

Watchers

Forkers

schema_plus's Issues

Recommend Projects

Recommend Topics

Recommend Org