I have a gem that I want to be capable of creating its own database (and later making migrations to that database if necessary). The gem uses ActiveRecord when reading and writing to the database. Short of embedding my gem in a non-serving Rails application just to get the necessary rake tasks, is there a best practice or community-promoted method for doing this? Attaching a whole Rails infrastructure to my little command-line only app just to get future migration upgrades seems like way too much overhead.
You can use DataMapper, which is a relatively lightweight ORM system (compared to ActiveRecord) in combination with an SQLite database. You don't need to use Rails for this, DataMapper drops nicely into a regular app, even something that isn't web-based.
You can use standalone_migrations gem to manage ActiveRecord environment outside of Rails: https://github.com/thuss/standalone-migrations. If you include your migrations or schema into a gem package, consumers of your gem can recreate db structure from scratch. I agree with robbrit that SQLite is the easiest choice for a database.
Related
I'm starting a new project and I have maybe three resources defined. Not a lot of code so far. (Rails 3.1)
But I'm interested in trying out DataMapper. I'm used to ActiveRecord (and actually enjoy it) but I'm always on the lookout for new things. Plus, my application uses Backbone.js but I don't believe that's relevant.
So how hard is it to switch out the ORM "mid-app" like this and do you think the learning curve to DM is that hard?
PS, there is a chance that I might be using other engines alongside my application. Such as MongoDB running along with Postgres. Will DM be at an advantage there?
To use Datamapper itself, there isn't much to it but it is some of the Rails niceties that require additional work (like the SQL execution times in "rails s") and there is also the rake tasks.
Check out dm-rails - They have a template that you use to provision the initial Rails project that sets it up with everything for Datamapper. You can also look through the source and see how it hooks everything. There is a small issue if you use database-backed session stores with Datamapper, which involves a monkey patch.
I have a simple Sinatra application that needs some persistence storage. If possible, that database should offer some access by id, and keyword search/find options.
Considering the nature of the to-be stored items, a document-based database seems the best fit.
Obviously I have considered MongoDB and CouchDB, but all have one problem: they introduce dependencies on third party services. I don't want that.
My users should install the Sinatra app as a gem, with its dependencies, run a single command and have everything running.
I am looking for solutions that come as a gem, run under the current user and are really simple. A prepackaged mongoDB would do, too, but I cannot find such a thing. Is SQLlite my only option?
It sounds like you want DBM (which gives you access by id) and Ruby/odeum which gives you keyword search.
You may want to consider either a self-standing database like SQLite and Redis (no-SQL), or an ORM like DataMapper.
I prepare to develop one project, which has no UI. The project just need to interact with database, so is there any example for reference ？
Does your app have ties to a Rails-based app and need to read the Rails configuration files? Or, is it entirely stand-alone and have no Rails interaction?
ActiveRecord is OK for that, but if I don't need Rails compatibility I use Sequel. It's a great ORM that I find to be much more flexible.
If you need Rails compatibility and want to use ActiveRecord, look into using rails runner. From the docs:
runner runs Ruby code in the context of Rails non-interactively. For instance:
$ rails runner "Model.long_running_method"
Rails runner is for command-line apps that don't need the HTTPd server or user-interface of Rails. I use them for things like an app that runs daily to ftp files from a site for analysis. It has to write to the database, so it has access to all the models I've defined, but it never needs to present anything to the user since it is invisible to them.
How to properly implement RSpec, ActiveRecord and Factory Girl in non-rails application. I also need that every test case would run on a clean database.
Thanks!
ActiveRecord outside of Rails is a pretty common request, so there's plenty of blog posts and tutorials on getting it done, just Google it. Using it outside of Rails isn't very different from using it within Rails. The major difference is that you'll have to handle the things that Rails usually does for you, like creating the connection, and handling migrations.
RSpec was not designed specifically for Rails, so using that outside of Rails is a non-issue. Just follow the standard tutorial.
Same thing for factory_girl. Rails support was separated from factory_girl proper and moved into a separate gem, so using it without Rails is also simple. Its standard README should be sufficient.
For cleaning the database, use the database_cleaner gem.
Is it possible to use ActiveRecord for storage and query in a MacRuby Cocoa application?
If it is, are there any resources that shows how?
Are there any reason why ActiveRecord should not be used?
Yes, it is. It's a Ruby library, you can use it without any problem.
However, ActiveRecord is a quite huge library. You might not need all its features. If you simply need to connect to a database and perform operations, I strongly encourage you to give Sequel gem a try.