Slashdot Mirror
Exploring Active Record
An anonymous reader writes "Everyone knows that no programming language is a perfect fit for every job. This article launches a 'new series by Bruce Tate that looks at ways other languages solve major problems and what those solutions mean to Java developers. He first explores Active Record, the persistence engine behind Ruby on Rails.'"
I've volunteered to create a recipe-wiki-site-thing for a friend, and coming from a background in C and SQL there was just too steep a curve to map a procedural train of thought and pre-planned SQL onto the Rails way of doing things. I already created the database schema, wrote all the SQL to get the information I want, have a lot of HTML written for the general template, and was looking at abandoning much of it for controllers, models, automagic foreign key relationships, automagic methods popping out of thin air.. I wanted more control I guess.
So I've done most of the site in PHP instead. Direct, to the point, fast enough (though I'm thinking about a rewrite in C for a pure CGI/FastCGI binary), a minimum of automagic hand-holding - just start each page with sanity checking, authorization, the SQL the page needs and nothing more, and then format the output. No wondering how many hundred methods have been created that I don't know about, what happens when a record is deleted/updated (I'll let the database handle null/ignore/cascade thankyou) or whatever else Rails is doing behind my back.
I'm a C guy - I don't like things being done that I don't explicitly ask for. I want init() functions. I want implicit declarations. Heck I don't even like C++ for fogging-over-functionality with inheritance, virtual functions and overloading.
Ranting aside, I can see how Rails would mesh with a lot of people. But it's definitely not for me, and I guess (hope) a few other nutjobs around here.
Don't Hate, Gestate
People, and usually not developers, are still caught up in the idea of a programming language instead of the concept of applying an API or SDK to a task. My favorite example of this is the often held C++, C#, Visual Basic debate -- everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.
A politician giving an address in German instead of French is not more effective as his points will still remain the same. The language isn't the tool, the intention is the tool.
Kind of ironic, really, given that Ruby actually comes from a country that uses a non-ASCII alphabet... well, not really an alphabet at all, actually.
I recently wrote two applications that included a registration form, validation checks, sending email with a URL to click to confirm the registration and finalizing the registration.
I wrote the first one in Java and the second one with Ruby On Rails, to learn the language and experiment with the framework. The Rails application needed half as much time to be coded than the Java one, despite being totally new to Ruby and to Rails.
The merit goes almost entirely to ActiveRecord and expecially to the validation feature.
Another time saver is Ruby's being interpreted instead of compiled. That saves a few time at every change to the code, even if strong type checking at compile time would have occasionally saved me a lot of time. It's difficult to assess if I gained or lost time.
What I'm looking forward to now is a good ActiveRecord implementation for Java because Rails is great but Ruby's syntax is really appalling. Even Perl (admittedly one of my languages of choice) looks more consistent. On the other side, halving development time is something that tempts me a lot. Java on Rails would be great.
I've recently been writing a project with Rails, using MySQL as the backend. Supporting UTF-8 has been no problem at all. UCS-2 support may well be lacking, but it's certainly not like you can't support people with non-ASCII alphabets.
PenguiNet: the (shareware) Windows SSH client
Ask developers at Microsoft if they developed Vista in 100% C# before taking that perspective young man, you might be surprised at the response that you get.
Thank you for illustrating my point.
Microsoft has, in fact, hired many of the top language designers of the world because they think languages matter.
Microsoft has been pushing hard for a move to managed runtimes.
And Microsoft's severe problems with their previous C/C++ efforts are the reason for that.
So, lots of people at Microsoft have come to the conclusion that languages matter a great deal, and that's why they are investing probably hundreds of millions of dollars in that.
What turns me off is forcing you to store all your data persistence into SQL and relational tables, when it is clearly a hierarchy of objects. Why does everyone think they have to do that? The software would function much more simply and the data would typically work better without it.
It is great to see that developes are finally beginning to see the downsides of Rails!
The thing is, not everyone does think they have to do that! There are perfectly good high-performance ORM systems that do allow you to work with a hierarchy of objects and use rich but portable query languages - examples are Hibernate, JDO and the soon-to-be released JPA (Java Persistence Architecture).
They are as DRY (don't repeat yourself) as Rails, as with quality implementations you can automatically generate schemas from objects, or get object hierarchies generated from schemas, and they don't have to rely on endless configuration files (you can define minimal relational information as annotations in your objects).
Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability. You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability, the ability to do this means you get high-quality SQL largely automatically.
Unlike Rails, they work extremely well with both legacy schemas and schemas that are shared with other applications a developers.
Unlike Rails, some of these APIs (JDO) don't restrict you to relational systems - you can persist just as easily to things like object databases, SOAP services, LDAP, text files, filesystems etc., without changing a single line of code, and all the while using a rich query language!
These products and APIs are available right now, have open source implementations and have been used successfully by a very large number of developers for years.
My view is that they make Rails look primitive.
Yes, Ruby and it's author have an interesting attitude to string representation in general and Unicode in particular. It's partly what inspired me to write this:
Psychology of Unicode in Japan
It's really been a very interesting struggle between people's psychological and I.T. needs -- a struggle that's pretty well over now, but has left behind things like Ruby's way of doing things.
Whence? Hence. Whither? Thither.
Well KODO is considered to be the best persistence layer for java around, I am glad that Bea decided to opensource the KODO EJB3/JPA layer under an Apache license. And I agree Hibernate is subotimal, there are issues with performance in certain areas, there are issues with mass data, and the whole many to many handly in combination with some of the Hibernate core people (not Gavin King he always is nice) in the JBoss forums gives it the rest. I cannot await to move away from Hibernate towards EJB3 JPA based on Kodo.
accordingly, things i dislike about active record:
1) it seems to mirror tables pretty directly;
2) i don't think the objects you work with in code should know how they are stored - this means they don't inherit or mix-in any database code at all. there should be separate classes that handle this.
this holds for other languages too, of course. python in this case:a Ticket may consist of data aggregated from several tables; the client code doesn't care about that. the TicketStorage class worries about storage.
now, inside TicketStorage, you might use your ORM of choice, or access the DB directly, or whatever. the point is, the public methods of TicketStorage draw the line in the sand between the code using the Ticket objects and anything storage-related.
that's my preference from a design perspective, anyway.
free software, open standards, open file formats, no software patents.
The ActiveRecord pattern is NOT new, and it won't scale out past a few dozen tables.
How many applications out there have more than a few dozen tables? I'd have serious concerns with a system that had a single application, with a single database, comprising of hundreds of tables. In reality such systems are quite rare--for every massive ERP implementation there are hundreds or thousands of smaller applications where Ruby on Rails' Active Record model would work very well.
For TOY applications, it might be fine, but for say something like an ERP system with thousands of tables, it just won't scale out performance or maintanence wise, never will.
There are other approaches to system design as well--how about applying a modular "UNIX philosophy" to an enterprise system with several
distinctly defined "TOY applications" each dealing with a smaller number of tables, all loosely coupled together? Even big, old accounting systems are broken into "modules" after all (which historically are more tightly coupled with the main system but still deal solely with a smaller subset of tables/files).
I, for one, like "toy applications". I don't think I've ever heard a developer get real enthusiastic about implementing or maintaining an ERP system--not the way a manager or marketing person does anyways. Come to think of it I don't know a lot of enthusiastic end users of such systems either. Perhaps a mega-corporation saves a lot of time and makes its business more efficient with its mega-ERP systems, however, feeding and caring of that beast is still tedious and annoying--it's just less tedious, annoying and expensive than dealing with mistakes, redundancies and general idiocy an enterprise has to deal with in the absence of a good business management system.
One thing is certain: there are different tools suited to different jobs, and Ruby on Rails/Active Record is best suited to smaller-sized applications where everything is developed from the ground up. Saying it lacks legitimacy because it cannoy scale to handle apps of gigantic proportions or properly interface to complicated, arcane legacy systems (ALL contemporary ERP systems in production use today are "legacy systems" IMHO) is like saying the familiar operator interface of an automobile is a failure because it cannot "scale out" to handle "real" vehicles like high-speed super-trains, jumbo jets or spacecraft. Over 90% of us never need to scale out past four wheels going up to 125km/h and carrying a couple of passengers.
And don't get me started on performance: Java was widely criticised for its performance, as were PHP and Perl for being interpreted and "slow"...however the use of all of those in very high-volume, demanding production systems. The hardware is out there to handle it now, and I've never heard people complain that Rails or Active Record are way too slow to handle the tasks asigned to them.