activegraph: Superclass mismatch when Neo4jrb generates model migration w/ trailblazer-rails gem

On a new install of Rails 5.1.1 with Neo4jrb (installed using the rails new myapp -m http://neo4jrb.io/neo4j/neo4j.rb -O option described in the setup docs), running rails g model User creates a user.rb file in the models folder containing

class User
  include Neo4j::ActiveNode
end

and a migration file containing class User < Neo4j::Migrations::Base and results in a superclass mismatch error when I try and run rake neo4j:migrate.

If I edit the migration file to update its class name to CreateUser, the superclass mismatch error is eliminated but I get a new ArgumentError: wrong number of arguments (given 2, expected 0..1).

I can’t seem to find much information on migration files in the docs, so I’m not sure what the argument error is referring to.

Runtime information:

Neo4j database version: 3.1.4 neo4j gem version: 8.0.17 neo4j-core gem version: 7.1.2 neo4j-rake_tasks gem version: 0.7.12

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 24 (19 by maintainers)

Most upvoted comments

Just released version 8.0.18. Give it a try!

cheerfulstoic on Jun 5, 2017

This is primarily a note to myself for when I have time to fix the handling of rails destroy model:

ActiveRecord’s migration handling is defined in https://github.com/rails/rails/blob/master/railties/lib/rails/generators/migration.rb

Importantly, ActiveRecord finds an existing migration by ignoring the file’s timestamp and just looking at the migration name migration_lookup_at(dirname).grep(/\d+_#{file_name}.rb$/).first

jorroll on Sep 16, 2017

Oh, wow, I didn’t even realize that there was a rails destroy model! 😉

I’ll have a look in a bit at that, and glad that you’re enjoying the gem! 😉

cheerfulstoic on Jun 5, 2017

Oh, duh! I missed that you were using the model generator. Definitely that should be creating a different class name. I think that would be easy, let me have a quick look.

The force: true is added when doing the generate_schema_migration because it’s creating a special migration to create the id_property’s constraint and the important thing there is that that the constraint exists (even if it was already created). This was partially because users had to migrate from a system in which constraints and indexes were created automatically by defining them on the models (which turned out to be difficult to support. In the normal case if you’re adding a constraint for any given field, it’s useful to know if the constraint is already there (though the force option is still available to you)

cheerfulstoic on Jun 5, 2017