Forgot your password?
typodupeerror

Exploring Active Record 266

Posted by ScuttleMonkey
from the language-midlife-crisis dept.
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.'"
This discussion has been archived. No new comments can be posted.

Exploring Active Record

Comments Filter:
  • by lifeisgreat (947143) on Wednesday March 08, 2006 @03:39AM (#14873135) Homepage
    Has anyone else played with Rails and been turned off?

    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.

  • Wrong Mentality (Score:5, Interesting)

    by MLopat (848735) on Wednesday March 08, 2006 @03:39AM (#14873137) Homepage
    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.
  • by syntaxglitch (889367) on Wednesday March 08, 2006 @03:53AM (#14873167)
    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.
  • Really a time saver (Score:4, Interesting)

    by pmontra (738736) on Wednesday March 08, 2006 @05:38AM (#14873446) Homepage
    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.
  • by Sircus (16869) on Wednesday March 08, 2006 @07:33AM (#14873826) Homepage
    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.
  • by idlake (850372) on Wednesday March 08, 2006 @08:21AM (#14873993)
    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.
  • by Decaff (42676) on Wednesday March 08, 2006 @08:54AM (#14874115)
    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.
  • by kahei (466208) on Wednesday March 08, 2006 @09:11AM (#14874185) Homepage

    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 [jbrowse.com]

    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.

  • by MemoryDragon (544441) on Wednesday March 08, 2006 @10:27AM (#14874581)
    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.
  • by WeAreAllDoomed (943903) on Wednesday March 08, 2006 @10:37AM (#14874655)
    i reject the notion that "the db *is* the model". that's crap - the db is the db. it's where you store the model.

    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:
    cn = <a database connection>
    ticketStorage = TicketStorage(cn)
     
    # get list of this year's unpaid tickets
    startDate = datetime(2006, 1, 1)
    endDate = datetime(2006, 12, 31)
    tickets = ticketStore.getUnpaid(startDate, endDate)
     
    # show the tickets
    for ticket in tickets:
      print "unpaid ticket number %s was issued on %s" % (ticket.number, ticket.date)
     
    ... (do some stuff with tickets)
     
    # save changes to database
    ticketStorage.save(tickets)
    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.
  • by Decaff (42676) on Wednesday March 08, 2006 @10:42AM (#14874705)
    One thing I like about ActiveRecord is that it is database agnostic. If I need to, I can move my app from MySQL to Postgres to Oracle with very little effort.

    You can move your app, but how much effort is there in moving your data model? For serious apps, quite a bit. Oracle has seriously different types of columns and restrictions on columns from Postgres or MySQL, and if you want to use really efficient SQL, you have to use SQL that is hard to port (MySQL has only recently got subselects, for example).

    This is why I think working in the opposite way to Rails - designing your data model in terms of classes and letting the ORM product generate a schema from that (still DRY, but in the other direction) makes far more sense - I can move my apps between those databases with no effort at all.
  • by Local Loop (55555) on Wednesday March 08, 2006 @10:47AM (#14874743)

    I agree with you, mostly. Rails is a god-awful mess under the hood. The programmers really abuse the language features (especially the ability to re-open objects) to the point where it is nearly impossible to trace through the code to figure out what is really going on.

    I tried it, ditched it and refuse to use it anymore. The last straw for me was the lack of respect for backwards compatibility in their version upgrades -- I had gotten halfway through a small a project and then they changed the API drastically!

    As for the methods they create behind your back, let's just call it what it is: Self Modifying Code. How the heck am I supposed to debug code that doesn't exist at design time?!?

    I too am a procedural guy. I used to write windows programs in C (Delphi now) and am currently doing a lot of embedded work in C. But there are some nice advantages to OOP for web development. For example:

    1. It's nice to have a common base class with a before() function that can handle auth and logging for the entire app.
    2. I can release app upgrades to beta users by copying, renaming and modifying a controller object and view directory
    3. Reusable GUI components!

    I am such a convert to (light, simple, uncomplicated) OOP that I have written my own Perl MVC framework to let me do it easily.

    But I feel that Rails' implementation of MVC is simplistic and naive. Also, despite all the hype, they haven't solved any NEW problems in web app development. For example, when is somebody going to tackle:

    1. standardized, cross-app, cross language/framework logins
    2. monolithic, parameterized page components that can easily be re-used in other apps
    3. easy support for query direction across replicated DB backends
    4. built in support for session sharing across multiple servers (with the session data kept in the DB, not in memory

    So yes, I am a fellow nutjob, but I have seen light of OO web development.

  • by dubl-u (51156) * <[2523987012] [at] [pota.to]> on Wednesday March 08, 2006 @02:22PM (#14877039)
    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.

    For which, I salute you.

    Personally, I'm a big OO guy; for anything beyond a thousand lines of code, I feel the object-oriented approach makes maintenance much, much easier.

    But what makes me bat-shit crazy is people who feel like you do but aren't smart or independent enough to be honest that either a) they don't really get OO yet, or b) they get it but prefer to work otherwise. So they go and write a bunch of semi-procedural crap in an OO language, half-assedly using the various OO features wrongly. I've heard this called "procedural object oriented programming" or POOP, and it is so much worse than either good procedural code or good object-oriented code. And honestly, 75% of the Java code I get asked to review is POOP.

    So I seriously and unironically salute you for knowing what works for you, and valuing good code over following the latest trends.

    And a little P.S. to my fellow Java developers: If you have a lot of objects with data and no behavior (just getters and setters), or a bunch of objects with no data and lots of behavior, then that is not object-oriented programming. The first is a struct; the second is a function library. Object = data + behavior. If you aren't sure whether you're doing OO work, read Domain-Driven Design [domaindrivendesign.org].
  • by WebCowboy (196209) on Wednesday March 08, 2006 @02:58PM (#14877366)
    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.

"Someone's been mean to you! Tell me who it is, so I can punch him tastefully." -- Ralph Bakshi's Mighty Mouse

Working...