I am currently trying to use the activerecord gem in Ruby but I'm quite confused on how to use the gem. What's the difference of ActiveRecord::Base, ActiveRecord::Schema and ActiveRecord::Migration? And when do I use them?
To sum up : AR::Base is the skeleton for a model. Your models usually are classes that derives from this one. AR::Schema is, well, for the schema of your db. You can see what it looks like in the file db/schema.rb. As for AR::Migration, it's in the name too : it's the skeleton for the migration files that you can find in db/migrate. You can check the rails guides & api reference to have more information on them.
Related
I am trying to post and save the form, which contains data for 2 models, they are connected with associations. But it fails on
Sequel::MassAssignmentRestriction
that the method for column from associated table does not exists. I understand the error and find the answer for rails. Which is to use
accepts_nested_attributes
but I am using Padrino, not rails. So I try nested_parameters but it didn't work and documentation tells just
The nested_attributes call defines a single method, association_attributes=, (e.g. albums_attributes=). So if you have an Artist instance:
which I understand that it is not what I need, for storing all with
#article = Article.new(params[:article])
and associated tables.
Please, do You know how to use it with Padrino and what is right way
Thanks
Question:
In a post-attr_accessible Rails 4 world, in what way do you recommend, if at all, annotating your ActiveRecord model class files to communicate its (database) attributes?
Further Thoughts
As part of a Rails 3 -> 4 upgrade, we are making a switch, and happily so, away from attr_accessible and to strong parameters in the controller. I understand and agree with the improvement in security via this switch. If you want to know more about this, the information is out there, and it's not hard to find.
But, I enjoyed, in my Rails 3 world, having those reminders of what attributes made up a class up there at the top of the model file. Especially since we're moving toward a world in which ActiveRecord classes are just DAOs, what else is the class but a collection of database attributes? I don't want to go to the schema.rb file just to remember them.
Am I thinking about this incorrectly? In a DAO world, should I be creating my ActiveRecord model class file and then never opening it again?
I know about the annotate_models gem and used it way back in the day. I was not a fan of having the attributes described in commented-out lines. (unreadable, hackish, fragile)
Thoughts? Opinions?
How about:
Person.column_names
If you are using an IDE or and editor that has a console feature this becomes an easy way to be reminded what attributes there are. I am no Ruby or Rails expert, still pretty new here, but I've been using Rails 4 almost exclusively and it just seems like you wouldn't need to see the attributes that often in the model. The params get whitelisted in the controller because that is where they will usually be used, no? If you don't want to use comments you could store an array of the attributes in the model:
my_attr = [:fname, :lname, :age, :height, :weight]
But is that really any more useful than a comment? Would there be a case of attributes that would have been in attr_accessible that wouldn't be in your whitelist in your controller? It would be trick if you put some code in a rake task that would run every time you ran
rake db:...
that would update the my_attr array in your model so you wouldn't have to remember to do it when you modified the model. I go into my models to add class methods and scopes, so I do see a value in it. But I work in RubyMine so I just click on the DB tab on the left side if I need to be reminded of columns that aren't in my whitelist.
I've started using DataMapper in my project, then I've found out that it is actually a frozen project. DataMapper 2.0 moved to ROM (Ruby Object Mapper), however the Property API from DataMapper was extracted to Virtus project.
What I need is to keep definition of particular class in one place (relationship + attributes) and I cannot allow to keep model in schema definition prior to the class as it breaks low level requirements for the project. I need to map classes to model (way of persistence), not model to classes.
So, I start wonder if there is any way to glue Virtus and Sequel or ROM together, to have attributes definitions in same class declaration and get the database schema automatically as I would in DataMapper. I am looking at direction how can I hook to Virtus machinery and add schema to model by DB.create_table() (Sequel)... or something similar.
Please avoid answers and comments that are not hints how to do that. If it is not possible, I just remove DataMapper and abandon ORM then and instead I will create repository of marshaled objects.
I have an ActiveRecord based application that is used via command line utilities. Having the models namespaced in such an application is advantageous for keeping the Object namespace clean.
I'm starting to build a rails application around these ActiveRecord models and, though I have overcome some of my initial troubles with using models in a namespace, I'm finding things are more verbose than I'd like.
What I want is to programmaticaly set a namespace for my ActiveRecord classes when used in the command line utilities and to programmaticaly not set a namespace for these models when used in the Rails app.
I know that the files themselves could be altered at runtime before being required, but I'm looking for something in the Ruby language itself to accomplish this cleanly.
hard to offer a great suggestion without seeing some code, but here are two possibilities.
It sounds like you have two clients for this code. Maybe make it an engine (just a fancy gem), you can add your paths to autoload paths, then use it from the gem without all the railsy crap getting in the way.
Maybe create a constant then reopen it in the models:
in some initializer
ActualNamespace = Class.new
DynamicNamespace = ActualNamespace
in your model file
class DynamicNamespace
class MyModel
end
end
DynamicNamespace::MyModel # => ActualNamespace::MyModel
Then for your command line app
DynamicNamespace = Object
Which is the same as not having a namespace:
DynamicNamespace::MyModel # => MyModel
Now you might wind up having difficulties with some of the Rails magic, which is largely based on reflection. I don't totally know what you'll face, but I'd expect forms to start generating the wrong keys when submitting data. You can probably fix this by defining something DynamicNamespace.name or something along those lines.
Autoloading, is likely to also become an issue, but I think you can declare autoload paths somehow (I don't know for sure, but googling "rails autoloading" gives some promising results, looks like it just hooks into Ruby's autoloading -- though I think this is going away in Ruby 2.0) worst case, you can probably define a railtie to eager load the dirs for you. This is all a bit out of my league, but I'd assume you need the railties defined before the app is initialized, so you may need to require the railtie in config/application.rb
Unfortunately, at the end of the day, when you start deviating from Rails conventions, life starts getting hard, and all that magic you never had to think about breaks down so you suddenly have to go diving into the Rails codebase to figure out what it was doing.
I'm trying to create a Rails app without a persistence layer (ActiveRecord, MongoMapper, etc). I've used --skip-active-record on rails new nice_app. This has changed the config/application.rb, but when I try to create new "model" with Rails generate - rails g model nice_class - it fail like a noob with:
No value provided for required options '--orm'
So, if I skip ActiveRecord I can't use Rails generators ?
Note the tasks that get called when you run rails g model nice_class:
invoke active_record
create db/migrate/20111227183458_create_nice_classes.rb
create app/models/nice_class.rb
invoke rspec
create spec/models/nice_class_spec.rb
The first thing you notice, is that it's using ActiveRecord to generate the model. Besides that, though, it's not doing a lot: creates a file in the migrations folder (which you don't need), another file in the model folder (which you do need), and a file in the test or spec folder (which you 'should' need). You can make these yourself if you want want, they are pretty close to being empty anyway.
For specifics about models not based on ActiveRecord, take a look at Ryan Bates' "Tableless Models" Railscast available here: http://railscasts.com/episodes/193-tableless-model.
If you are going to be making these kinds of non-ActiveRecord models a lot, you can write your own generator that does exactly what you want.
Best of luck.
The models that are generated by the Rails generators are subclasses of ActiveRecord, which only really makes sense in the context of an app with an ORM. You could certainly create models that aren't subclasses of ActiveRecord (and thus not associated with any ORM), but you'd have to do that manually.