As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been learning Rails since this summer and have written some successful standalone apps with it, and really have grown to appreciate nearly everything about Rails.
However, my current project is writing Rails as a front-end to a database that will be used for other things (web services, data warehouses, other apps connecting) -- and I am realizing that ActiveRecord, and largely all the Rails developed around AR, seem to be very one directional when it comes to this approach.
Note: I am not referring to a Legacy database, ie. one that we have to plug into, but was designed "back in the day"..
Rails seems to think it is, and should be, the only application working with this data. I am noticing it more and more when it comes to things like, composite primary keys (which is something you cannot just adjust, like table naming and column naming).
While I know there is a composite key gem, I feel like I am developing an entire MVC application dependent on this single gem working. I fear I will run into more and more things like that. I have looked into alternative ORM's, however it seems that many gems depend on ActiveRecord.
I guess I am a bit surprised and saddened at this apparently selfish angle that ActiveRecord has.
Anyone have any feedback or success about how Rails works with an enterprise level database?
Rails is built primarily as an "opinionated" web development framework.
What it is built to do out-of-the-box is full-stack web applications, where the entire system is built the "Rails way", which is the result of many decisions made by committers to Rails to keep the system simple and standard. The number of configuration decisions that need to be made are very small when you stick to the conventions.
These conventions include setting up your databases in a certain way. Primary keys are auto-increment and named 'id', foreign keys are 'foreigntable_id'. ActiveRecord is built-in and almost always assumed to be used (even when it isn't).
None of this means that straying from the standard stack won't work. Sequel and DataMapper work just fine. You can name your table columns (nearly) anything you want. If your application can do what it is supposed to do; that is the most important thing.
Yes, because you used Datamapper, now your app depends on Datamapper. How is that a bad thing?
Understand that because ActiveRecord is the default, that many other gems build on ActiveRecord to do their thing, so they may not work with Datamapper. That is not Datamapper's fault (or Rails').
The real question here, is "Is Rails, even when you use an alternative ORM or the composite keys gem, still more suitable and productive than X?"
I would argue that it is. So what that I have to set self.table_name= and self.primary_key= in every class? So what if I have to be forgo some gems that only work with ActiveRecord? So what if you have to consider database triggers and views. I deal with all these things, and Rails is still a joy to work with compared to everything else I've ever used.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I like to experiment with different languages to keep my interest alive when working on small side projects away from my day job.
I'm finding it increasingly difficult to steer away from Django and Ruby on Rails because of a couple of features they come packed with (or that are mostly default and easily integrated): authentication and automatic admin interface. Django comes with both, with Rails you just have to add ActiveAdmin as a gem and you're ready to go.
When I try to experiment with different frameworks and languages (Noir for Clojure, Express for Node), most of the times I find interesting languages I'd love to work with but whose "web framework" idea is just some convenience method for routing and parsing URLs and requests, leaving you alone with all the common and annoying parts of web development, like form validation, user authentication and profiling, having a working admin interface and so on, all things that Django and RoR provide to you for free.
What other languages and frameworks have such commodities? I'm aware of some PHP frameworks like Symfony, but I really have used PHP for too long in pas years and I'm pretty fed of it. Thanks.
Stick with RoR in my opinion. It's still a young yet powerful framework. It's well maintained and quickly plugged whenever a security risk becomes known.
It doesn't really matter what kind of MVC framework you use since it all comes down to the programmer. Ruby on Rails cuts out the painful part of programming (IMO) and allows you to do the enjoyable parts. Requiring knowledge of SQL is very minimal within Rails unless you're doing complicated scoping.
If I kept searching around for different languages to explore after I found one that suited all of my needs and then some, I would never get anything done. Moving from PHP/CakePHP to Rails is definitely an upgrade in my opinion, but at this point, you're better off committing to one language (Python/Django or Ruby/Rails).
I would stick with Django. Having worked in everything from classic ASP, ASP.NET, ASP.NET MVC, Java, PHP and Rails, I can state, unequivocally that Django is hands-down the easiest to work with, most profitable framework I've ever used.
Rails does have some pretty controllers, but it pales in comparison when you get down to functionality. Sure, Rails has lots of plugins, but Django has nearly everything you need under one roof. Django-admin alone is a friggin' gold mine. I work full-time as a Technical Architect, but also own my own business. Switching from Rails to Django in 2008 was the single best thing I ever did for my business.
If you want something flexible, modular, easy-to-extend and incredibly well documented - Django is your ticket. You also see far, far fewer of these lovely posts with Django.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In ASP.NET MVC applications and Java web applications, there's a common practice of keeping business logic in a separate package/dll and treating things like the database and delivery mechanisms (web application, web service, native mobile or desktop, etc.) as details that are plugged in.
Some of the advantages of this type of structuring I can tell are:
Reuse of the business logic with different delivery mechanisms or persistence layers
It's possible to run acceptance and unit tests of the business logic without having to load up a web framework or connecting to a database; the tests are very fast
Thinking of the application in terms of what it is, not how it is delivered
But this practice is not common in the Rails community; I don't see any Rails application where the business logic is kept in gems and the main ORMs all tie together persistence logic and business logic. Is there something about Ruby that makes structuring applications in the way I mentioned unnecessary?
Define "necessary". It's not necessary to do this in .NET or Java, it's convenient.
Rails apps often only expose the web app and related services completely within a single app.
Testing is similar; there's no need to break up application functionality in order to test code separately, and testing in Rails is no different: there are unit tests, specs, etc. which can run at any level of the code, and various mechanisms to mock out arbitrary portions of functionality.
Persistence layers are generally handled by the AR layer, although in practice it's fairly unusual to actually switch persistence layers (I've done so exactly once in thirty years of development, but that's anecdotal, obviously). In addition, some such switches in Ruby are transparent at the code level because of duck typing (e.g., I switched one app from a local DB to a service, almost transparently, by moving to ActiveResource instead of ActiveRecord, although I did not try to optimize anything afterwards, and the data model was pretty simple.)
All this said, IMO the Rails community has often overlooked practices from "enterprise" shops because Ruby-the-language makes it very easy to build functionality without a need to over-architect. The limitations of this only become clear after apps reach a certain size, however.
Recent trends in Ruby and Rails development include things I've done in the enterprise for years (and are much easier to implement in Ruby than, say, Java). Breaking out functionality into libraries for its own sake, though, isn't particularly useful. Identifying code that should be broken out is, but that happens across environments, when it's necessary to do so.
Rails is all about convention over configuration. And its opinion / best practices that have been set forth.
I don't see a big advantage to breaking down the BLL into Gems. Unless I have code that is independent of my web app and can be reused. For example I built a BBCode parser for a company forum recently so I packaged that up as a GEM that can plug into any rails app. There are thousands of GEMs on github that extend rails functionally.
The whole idea of making a GEM for a rails app should be code reuse. If you're separating your code just to try and follow more code separation then you're not relying on the rails conventions and if any other rails developers come on to your project they will have a learning curve.
You can use any number of testing systems that don't load the web framework in rails. Testing in a whole huge topic I'd look into RSpec and much more. And there are some ways to speed up testing (such as using Guard and Spork)
It all depends on the app really. The idea of Rails is to get your application done quickly. Java development in my experience has been painfully slow. Same for ASP. But those may have just been "bad experiences." Plenty of people swear by both.
Mostly, it's just about effort and configuration. Let's break down the individual points:
Effort: Setting up a new gem takes a little bit of time (and every project has its own particular set of dependencies - testing, mocking, documentation, etc)
Configuration: Since most Rails apps use ActiveRecord; it is a little more difficult to split out your model layer (though plenty of gems do this). Rails::Engine helps a good deal to mitigate the pain around that, though.
Cost: For most Rails projects, there's very little that you gain by splitting your code out into a separate gem/repo:
Most projects are not sharing code between each other (and when they do, they do set up gems)
There is - or should be, with proper setup - no difference to how you test the code; either in a gem or in your main project. (You can test models w/o hitting your controllers, etc - no problem)
The main benefit is to enforce explicit contracts between interfaces/layers - and that is just less prevalent in the Ruby community
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Background
I've written several production apps using Rails 2. I've gotten comfortable with it. I kind of have my Rails 2 routine down.
However, now I face a dilemma.
I have two new apps to write immediately.
Rails 3 has been out for a while now, and I wonder if it's time to get a book, invest some weekends and evenings, and start coding these and any further apps using Rails 3.
The things I write are usually stuff like "take our equipment inventory that's in MS Access and make a Web app of it," or "write an app that lets the secretaries post PDFs to our website and attach notations to them." (Those are made-up examples to give you an idea -- not the actual apps I'm working on or have ever worked on.)
Side note
On a personal level, I do understand the value of learning for its own sake and I am genuinely curious and interested in learning Rails 3. But I also have to respect time and energy limitations. I'm curious and interested in a lot of things. So I have to choose carefully.
Main question
What features / capabilities / improvements does Rails 3 have that might make the investment of time and risk worthwhile?
Or to put it another way, if I invest a week or two on Rails 3 tutorials, will it pay off in huge times savings later because Rails 3 development is way more efficient?
Other question
Is there a major downside to just sticking with Rails 2 for another few years or another four or five apps? Some looming danger I should be aware of?
Here is my take on it:
New plugins and gems will be developed for Rails 3.x, not Rails 2. And what speeds ups development most, are solutions supplied and maintained by a community.
Bundler. Although it can be used with 2.x, I admit.
Engines! It's not well docummented at the moment, and maybe a bit buggy, but I feel it will be an enabler for nice things.
Finally, and most important - you'll wake up one day, as a master in Rails 2.x, when a situation will require from you being a moderate Rails 3x framework user. That's inevitable imho.
And a transition to Rails 3 will not be as near as painfull where we had only beta / release candidates. So I encourage you to go for Rails 3.
There's a list of the most major changes at the Rails weblog, and others in the official Rails documentation. A lot of the changes involve cleaner syntax (some of the bigger ones being unobtrusive javascript and new routes syntax) and simpler ways to do common things (ActionMailer, chainable AREL).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
DataMapper idea is definitely better than ActiveRecord. It has one API for a variety of data stores, including RDBMS and NoSQL stores.
DataMapper is much smarter then ActiveRecord. It has "Strategic Eager Loading". This feature single-handedly wipes out the "N+1 Query Problem". Additionally it allows lazy-loading of heavy fields like Text property. DataMapper allows you to create and search for any complex object graph simply by providing a nested hash of conditions. ActiveRecods is unsuitable to be used for associations in production. include method is ugly and unconfigurable. In October 2010 Josh Symonds makes a patch for this method to allow fields to be excluded from eager loaded. But that path was ignored and today in rails3 we have same ugly include method.
Even in Rails3 with brilliant AREL, ActiveRecord is far from the best orm for rails. You may say "wow, that new gem metawhere allows to write nice code like Article.where(:title.matches => 'Hello%', :created_at.gt => 3.days.ago)". But wait... DataMapper supports this out of a box! Maybe instead of modifying ActiveRecord to looks like DataMapper better is to extend and support better orm? More details of DataMapper can be found at http://datamapper.org/.
I think, that rails in later releases should allow us to select which orm to use, like now it allows a database selection. Even it will has only one option "ActiveRecord", people will search for available alternatives. When I was starting to learn rails, I thought that there is support only for ActiveRecord. And later I did not even try to look for something else.
Why I am writing all this stuff? I think, that we need to pay more attention to this nice ORM. If you are developer of some popular or not so popular gem, think about adding support of DataMapper. DataMapper community should write some migration guides from ActiveRecord or another ORM and keep documentation uptodate and your may help them. As for me, DataMapper community needs more people and you may be one of them.
The only disadvantage of this ORM is lack of documentation and you may help.
So what do you think about that?
Rails 3 allows you to use Datamapper, just not by default. It you do want to use datamapper with rails 3. Just do this
rails new project_name -m http://datamapper.org/templates/rails.rb
Rails allows you to select, you can even use the --skip-active-record option. :) ( May not be straightforward but its there.
And yeah, Datamapper is awesome. :)
The lack of documentation is a huge issue. I've begun my databasing using DataMapper and have since decided to implement a web interface for my data. Incorporating DM into Rails, as a beginner in each, has been a tremendous challenge. Hence, I'm curious, do you know of any resources which show DM/Rails usage? I'd love to be able to see something when I'm not sure how to proceed.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Is it architecturally sound to use Rails and Oracle?
My concern is that Oracle would be too "heavy and hi-end" for Rails.
Any thoughts?
Thanks.
The database needs of Rails more or less boil down to tables, indices and CRUD.
Anything that provides those ought to be able to serve as the back-end to a Rails app, and Oracle certainly does those parts somewhere among the bloat vast range of features it provides. If you can use ActiveRecord migrations then you shouldn't need to worry too much about platform-specific aspects anyway.
The oracle-adapter for ActiveRecord (which needs to be downloaded separately and placed in activerecord\lib\active_record\connection_adapters, btw) makes use of Oracle-specific elements where appropriate, the main one I can think of being the use of sequences for id generation.
The Oracle query optimiser is very smart, probably rather better for complex multi-table queries than, say, MySQL.
If you're looking at Oracle as a back-end for an externally-hosted site, then I'd be sceptical on cost grounds, as well as the reservation already stated about availability. But I suspect that the question relates more to what's already available in-house, in which case I'd say it's about as "good" a solution as you can get.
I'm developing intranet applications on Rails/Oracle, using OracleXE locally for development, deploying to some "big iron" machine (it's someone else's job to care for it, I don't even know what OS it's running) for production.
EDIT: It's worth looking at the activerecord-oracle_enhanced-adapter (it's a gem) as a replacement for the built-in oracle adapter, if only for the improved handling of date/datetime values (Oracle only has one column type for both: DATE). It's probably saved me from a breakdown...
Why too heavy? Oracle it's just a database that can be simple to heavy depending on your use. Today Oracle have a lot of editions to accomodate any use, for instance the little one Oracle XE.
If your are happy with Oracle, use it. Don't worry.
The problem that you may suffer when using Oracle as Database is you can't find many hosting companies offering oracle as choice for your database on web.
also oracle like a giant DB, if you don't need the specific features in it, why use it?
Another thing to consider regarding Oracle and Rails: none of the full text searching plug-ins for Rails support Oracle at this time. Indeed, pretty much only MySQL and PostgreSQL are well-supported by the various full-text options.
This is not to say you won't be able to do full-text searching if you use Oracle, just that you will not be able to use any of the existing plug-ins that make doing so simple.
I'm currently using Oracle with some Rails applications. There are both standard ActiveRecord and JDBC-ActiveRecord adapters (I'm hosting some apps with JRuby) and for the most part, things work great.
I would suggest using the enhanced ActiveRecord Oracle adapter though.
http://rubyforge.org/projects/oracle-enhanced/
But if you're not locked into Oracle, go with Postgres or MySQL.