Follow Slashdot stories on Twitter

 


Forgot your password?
Close
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 More

Exploring Active Record

Comments Filter:

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Wednesday March 08, 2006 @03:38AM (#14873133)
    Comment removed based on user account deletion

  • Anyone else Railed-out? (Score:4, Interesting)

    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.


    • So I've done most of the site in PHP instead... just start each page with sanity checking, authorization, the SQL the page needs

      TBH It just sounds like you don't know what you are doing.
    • You must've really HATED ActiveRecord's pluralization thing. Heh.

    • Re:Anyone else Railed-out? (Score:4, Insightful)

      by soundofthemoon ( 623369 ) on Wednesday March 08, 2006 @04:12AM (#14873213)
      If you don't like it, don't use it. Like every other tool/framework/system ever developed, Rails will work for some and not for others. I've found Rails to be extremely productive and maintainable, but I'm an OOP die-hard and the approach is easy for me to grok.

      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. The other thing I like is that it provides a clean separation between data storage and business logic. Database programmers seem to hate that approach because it shifts the center of gravity away from the database and toward the web app. This is great for maintainability of application code, but I don't know how well it works for sharing data among multiple apps. I don't know if anyone has gotten ActiveRecord models to support the same level of integration as you can get with multiple apps running off of one database - I think there needs to be more work done to enable that, but I expect to see that work done fairly soon.

      The other cool thing about ActiveRecord is the use of metaprogramming, as discussed in the FA. I don't think we'll ever see a Java persistence layer that is as functional and easy to use as ActiveRecord, because the kind of metaprogramming tricks that Ruby enables are so much harder to do in Java.
      • 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.

        That's all well and good, for a subset of database functionality. ActiveRecord reminds me of wxWidgets - smoke and mirrors, bloat and lowest common denominator functionality. But don't get me wrong, for a great many jobs it's adequate and there for the taking.

        The other thing I like is that it provides a clean separation between data storage and

        • Re:Anyone else Railed-out? (Score:5, Insightful)

          by shmlco ( 594907 ) on Wednesday March 08, 2006 @06:41AM (#14873660) Homepage
          "Inexperience can mitigate the benefits of any technology..."

          Inexperience and ignorance. And it sounds as if it applies to you and to this situation. I don't see how you can rant against "bloated" technologies you never bothered to learn. Without that knowledge, you don't understand everything that's happening behind the scenes and, since that scares you, you stick with the subset of the developmentatl universe you do know, no matter how appropriate, or inappropriate, it may be to the problem at hand.

          I strongly suspect that once you've moved on to other victims, the next developer the guy hires will take one look at your carefully-crafted optimum solution, shudder, and then rewrite the whole thing.

      • Well the JPA simplifies to a big degree the mapping instead of having a class and a xml descriptor describing every field you normally have @Entity public class Table { @Id Integer id; .... so things have become easier, but there are certain limitations of course

        you have the java inherent setters and getters, which blow up your code (although the usually are generated, no one normally codes them by hand

        something like a query over a method is not possible you still have to go over the persistence api

      • 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).

        Th
        • PostGres->Oracle is not nearly as bad as MySQL->anything else.
          SQLServer->Oracle, SQLServer->DB2, DB2->Oracle, etc. doesn't happen all that much. If only more databases supported DOMAINs, i.e., CREATE DOMAIN UserID as integer.

          DeZign for Databases is pretty good at slurping in a database schema from one platform, and after changing the target platform, converting the schema to the desired database system.

          As far as "hard to port" SQL, unless you're using MySQL or old versions of databsae apps, t
          • As far as "hard to port" SQL, unless you're using MySQL or old versions of databsae apps, this isn't too much of a problem for most SQL heads, even when you throw in database-specific functions or idioms.

            That is easy to say until you are dealing with tens of thousands of lines of legacy SQL.

            And it all depends on how much trigger/stored proc code you have to migrate. Tables/Views are pretty simple to move.

            Not really - just look at the range of different column types in PostgreSQL or Oracle - converting is no
        • actually, you can generate DDL from an OO class definition in Rails by using migrations, which is the built-in way Rails handles updating databases to the current version. you do "script/generate migration " and a skeleton gets generated for you, and then you fill it out. then just run "rake migrate" and DDL is run that generates your tables. here's a writeup of it [ttono.us].
    • I want init() functions.

      90% of the time, when you call an init() function, you're going to call a free() function too. Let C++ do the grunt work for you. Use the RAII pattern [hackcraft.net].

      Put your init() code in the constructor and your free() code in the destructor. That way you won't forget to call free().

      Heck I don't even like C++ for fogging-over-functionality with inheritance, virtual functions and overloading.

      You don't have to use those C++ features if you don't want to. You can program in C-style in C++ if

    • > sanity checking, authorization, the SQL the page needs and nothing more,

      Don't repeat yourself:
      http://c2.com/cgi/wiki?DontRepeatYourself [c2.com]

      k2r

    • Re:Anyone else Railed-out? (Score:5, Insightful)

      by JulesLt ( 909417 ) on Wednesday March 08, 2006 @05:36AM (#14873438)
      Which bit is causing you the problem - Ruby or Rails? My understanding is that Rails is simply providing, well, Rails to give you a rapid framework for your Ruby app - provides you with a web page that's a 'default form' along with the related MVC code. It's similar to other frameworks that provide default pages from ORM mapped classes in other languages, but I thought it was Ruby, rather than Rails, that was getting people excited.

      I'm an 'SQL' guy myself and I'm not convinced by ORM tools - or at least the way they're being hyped as a solution for having to understand the DB (Newsflash : SQL is supposed to be an abstract query language so that the developer doesn't need to understand the DB - and look how that worked - answer : Mostly it does, but when it goes wrong you're dealing with a black box). I also think that the view of many Java (and Ruby) developers that a DB provides 'persistence' is wrong. It's a failure to understand relational theory - which at least, unlike most object modelling techniques, has a firm mathematical foundation. It's also a failure to use the tools provided to you (and when Bruce Tate complains about Java productivity, this tendency of Java developers might be part of the problem - it's 'not invented here' syndrome).

      You could have used Ruby rather than PHP (a comparison I'd like to see) and I also think that there is much to be said for the MVC structure compared to shoving everything into each page.

      It feels a bit clunky in the current paradigm (pages generated on the server and refreshed to the client, client events sent to server) but it works very well as a design, and I can see it becoming more important again as browser apps support more dynamic features - getting back more towards a client-server architecture with the model on the server, view on the client. (Or more likely a local model for performance and some form of background syncing).
       
    • Has anyone else played with Rails and been turned off?

      I've seen one or two... here [slashdot.org] for instance. I've yet to try it myself, but I'm looking forward to it... when things have calmed down a bit on my current project. I've been a bit turned off by the constant one-sided evangelizing by some of the enthusiasts though.

    • Re:Anyone else Railed-out? (Score:5, Insightful)

      by ubernostrum ( 219442 ) on Wednesday March 08, 2006 @06:41AM (#14873661) Homepage

      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... you basically wrote the application (minus the controller), and then started thinking about using a different platform? Is it any surprise that you didn't want to switch over to Rails (disclaimer: I'm not a Rails guy. In fact, I work for the competition [djangoproject.com])?

      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.

      OK. It's not like somebody's holding a gun to your head and saying you have to use a framework. Personally, I see a lot of use cases where a framework makes development a lot simpler and easier to manage, because so much of the tedious overhead of web-app development has already been done for you. Think of the framework in terms of an operating system you're programming for: rather than writing all your own device drivers, routines for drawing stuff on the screen, accepting keyboard/mouse input, etc., you've let someone else solve those problems and you're just using the provided APIs to hook up the logic that's unique to your application. And with a framework, rather than write database drivers, routines for accepting and routing input, etc., you've let someone else solve those problems and you're just using the provided APIs to hook up the logic that's unique to your application. Using a web framework is no different, really, than using any other shared library.

      As for all the cruft you complain about, when was the last time you used every single bit of functionality provided by a shared library you linked a C application against? Or is it only bad to draw in automagical functions you won't use when the application isn't being compiled? ;)

    • Rails is still suffering growing pains. After that is over, it will have the problems of maturity. Rails has a lot of good ideas, and leveraging Ruby is one of them. But Rails is not well documented. It's almost as if the Rails devlopers have never seen really professional documentation and are happy to just look at the Rails source for information. For example, the API docs don't have a search box.

      I think Ruby and Rails are about the right ideas for our current and near future environment -- cheap c

      • As for rails documentation, the freely available stuff is widely disbursed, and disorganized. The real thing is the Agile Web Development with Rails book by Dave Thomas and DHH, of which the pdf version can be purchased for ~$22USD. The book is excellent, and provides a fairly comprehensive overview of rails development, but I can't help but wonder if the utter lack of comprehensive, good, free, docs isn't the result of the sales push for this book. Granted, this is an open source project--go set up a do
    • So, you like to re-invent the weel.

      Thats ok, sometimes I like to thinker too and understand how things work at the core level, but when you do that you waste too many time doing things that already has been made, and thats not cool when youre working serious project.

      Rails is about speed, is about getting your job done in less time, with less effort.

    • 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 dra

      • 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!

        This is an unfortunate side-effect of working in a pre-1.0 environment, regardless of what it was. I believe the current plan is to not break any APIs until 2.0 hits (and maintain the 1.x branch for security updates once 2.0 hits)

        As for the methods they create behind your back, let's just call it what it is: Self Modifying Code. How the heck a

    • Yep

      It's nice. Ruby is nice too, I like it. I guess there are 3 things that stand out to me, Rails is still a toy compared to j2ee, I've been doing "opensource" professionally for nearly 10 years and good enough usually isn't good enough. There seems to be a lot of consultant types pushing the rails way and it's because they've never finished anything.

      Second, I'm skeptical of religion in technology. Ruby and rails has a ton of religion going on. Enough that it's not just advocacy, it's crossing ov

    • 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 b

  • 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.
    • You are right to an extent, but ignoring the language issue entirely is also not a good idea. While syntactical differences are hardly important, semantics of the language can change a lot of things for the better (or worse), and strongly shape the 'paradigm' (compare e.g. JSP to SISCweb).

      And yes, language is a tool, actually. So is an SDK or a framework. So choose your tools wisely.

    • language matters a great deal (Score:5, Insightful)

      by idlake ( 850372 ) on Wednesday March 08, 2006 @05:12AM (#14873370)
      everyone has their syntax preference, but at the end of the day its the paradigm you apply that matters and not the language.

      The differences between C++, C#, and VisualBasic are far deeper than syntactic. C#, for example, guarantees fault isolation, while C++ does not. C# has full reflection, while C++ does not. Programmer productivity in different languages can be orders of magnitude different.

      Of course, most working programmers have the same superficial view of programming languages as you do and will make the same glib and ill-informed analogies to natural languages that you did. That's why people keep choosing C and C++, believing the differences to other languages to be merely syntactic, and then producing code that crashes, silently mangles data, and has gaping security holes.

      Fortunately, the herd mentality is driving even people who don't know what they are doing away from C/C++. Even your own company bills itself as a .NET development house. You may not understand why C# is better for you than C++, your productivity may not increase, but the fact that you have switched means that your software will ultimately still cause fewer problems.
      • 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.

        • Re:language matters a great deal (Score:4, Interesting)

          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.
      • Programmer productivity in different languages can be orders of magnitude different.
        Most studies show that this is blatantly untrue -- programmer productivity is generally independent of language chosen. In other words, given an 'average' programmer with X years of experience in their language, they will take about the same amount of time to complete a given task in their language.
    • That debate only really seems at all applicable in Windows, however, I should point out that those languages are very different animals. C++ is not only syntactically different, and semantically different, but its capabilities are actually different. C++ has no garbage collector, C# does, for instance, unless you're talking about managed C++, and things of that nature.

      See... it's not JUST language, though it doesn't play as major a role as people like to think.
  • I like rails, but the poor apache integration sucks.

    But ActiveRecord is awesome. Most of us build databases that work like objects already.. so an object oriented interface to your database is very easy to use and maintain.

    • Re:rails (Score:4, Funny)

      by syntaxglitch ( 889367 ) on Wednesday March 08, 2006 @03:56AM (#14873172)
      Meanwhile, people who actually understand the value of and principles underlying relational databases grit their teeth and fight the urge to beat people with blunt objects.

      Not me, though. I never "got" relational database theory and am quite content to give people nightmares with my naive object-biased approach. :)
    • Well, Apache integration doesn't suck, you just have to spawn Ruby through the FastCGI interface. And it's definitely worth it, even for PHP, using FastCGI is really not a bad idea.

      RoR also perfectly works with Lighttpd and unless you absolutely have to use Apache, you should have a look at it. Its lightweight, modular and speedy. Since I migrated from Apache, I never looked back.

  • Uhhh.... (Score:5, Funny)

    by wbren ( 682133 ) on Wednesday March 08, 2006 @03:59AM (#14873175) Homepage
    Everyone knows that no programming language is a perfect fit for every job.

    I program in raw machine code. It's a perfect fit for every job, every time!

  • Still looking for an IDE (Score:4, Funny)

    by bogaboga ( 793279 ) on Wednesday March 08, 2006 @04:02AM (#14873186)
    I am still looking for a Ruby IDE on either Linux or Windows. May be I am looking for what does not esist, but my sense of an IDE is something like Access/VB for Microsoft's Jet Database Engine.

    Here, we simply drag and drop then program the logic behind all those widgets we've dragged onto the form. I also looked for something in relation to Python but could not find anything! I taught VB myself using this method. Current IDEs I have looked at make things confusing. Am I looking for what does not exist? Hope not!

    • - http://wiki.python.org/moin/IntegratedDevelopmentE nvironments [python.org]
      If you need a drag'n'drop gui editor, try Eric (pyQT( or BoaConstructor (wxWindows).

    • Try RadRails [radrails.org] - it's the best Rails-specific IDE I found during my brief searching. I noticed a few bugs, but at least it's still being developed.

    • Re:Still looking for an IDE (Score:5, Funny)

      by k2r ( 255754 ) on Wednesday March 08, 2006 @04:46AM (#14873314)
      > Here, we simply drag and drop then program the logic behind all those widgets
      > I taught VB myself using this method.
      > Current IDEs I have looked at make things confusing.

      Nothing personal but: This explains much of the VB code I had the misfortune to see in my life.

      k2r
    • What you have done leads to unmaintable code. Since the greatest part of the software development lifecycle is the debugging, maintaining, and refactoring part using VB actually is a drain on the productivity of your team when you measure the entire lifecycle of your application.

      Sure it only takes a day to slap controls in a form and bind some controls to a SQL statement but good luck trying to find a bug or refactor when you decide to change a field name.
      • I do a lot of quick-hack Access / VBA stuff at work. Usually I start by designing the tables, relationships, queries, reports etc, and then put together a GUI afterwards. I prefer to keep as much code as possible in separate modules rather than in the form itself - mainly because I forget the stuff's there otherwise, and you wind up with fossil code left behind from long-since deleted controls - but the grandparent sounds like he's doing similar things.

        Apart from its inherent inadequacies compared to 'rea

    • Java Studio Creator 2 is your friend... Exactly what you are looking for, and it is free.

  • No kayaking for once! (Score:4, Funny)

    by LarsWestergren ( 9033 ) on Wednesday March 08, 2006 @05:23AM (#14873399) Homepage Journal
    I'm amazed, a whole article by Bruce and not a single anecdote about kayaking. His writing is improving. :-)

  • 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.
    • This would be possable in theory.

      But your talking java programers here. Look at what the java community has come up with to solve the same problem -- JSP, plus struts, plus JDBC
      but that proved inadequate so they stacked the whole mighty ediface of J2EE
      on top of it.

      That the Java communuty could come up with a simple clean usable
      solution for anything is no longe feasable.

      If you want to see a Java programmer self-combust just set the following
      simple task:
      "Define 'bloat' in less than 9000 words".

  • Rails rocks (but isn't a silver bullet) (Score:5, Informative)

    by PetriWessman ( 584648 ) <orava AT orava DOT org> on Wednesday March 08, 2006 @05:53AM (#14873500) Homepage

    I've been playing around with Rails and AR quite a bit lately, and it has changed the way I think about programming in many (positive) ways. I come from a heavy Java / J2EE background (do that for a living, serverside systems), and Ruby + Rails is a breath of fresh air. Ruby is simply a wonderful language, there is something very "zen" about it, and Rails is inspired. Sure, it builds on a lot of old concepts, but the brilliance is where it leverages the power of the Ruby language to do things in very efficient and nice ways.

    Yes, there is a lot of "black automagic" involved in Rails. It's where the power is, and you can override pretty much everything is you want to. If you're uncomfortable with magic stuff happening behind the scenes and don't want to learn Ruby so you really understand that magic, Rails might not be for you.

    I'd claim that pretty much every serious programmer (VB scripters don't count :) should learn Ruby, at least the basics. It might not become your new favorite language (like it has for me), but it will give you a fresh new perspective on how to code stuff.

    Ruby does have a few downsides:

    • There is no Unicode support. For a language coming from Japan that's surprising (and sucks). I'm given to understand that fixing this is in the roadmap for Ruby(?).
    • It's an interpreted language (like Perl, Python etc), so if speed really is an issue for you then it's not a good choice (for most things nowadays, Ruby is more than fast enough)
    • The scoping of variables in blocks is a bit funky.
    • Some of the organization in the standard libraries is a bit weird, and there is some repetition of functionality. I think this is due to historical reasons (std lib code has evolved over the years)

    (there are probably more, but I'm still only learning the language)

    As for Rails, well, again there are downsides. Nothing is perfect.

    • No Unicode support (inherits Ruby weakness). For web apps, this really sucks.
    • Poor localization support in general (again, sucks).
    • ActiveRecord is nice, but works best for from-the-ground-up projects. Integrating with a legacy schema might get ugly, a mapping layer (like Java's Hibernate) would work better there.
    • No support for clustering and other heavy-lifting technologies. If you're building a seriously big app, Rails might not be the optimal choice. But face it, 99% of web apps don't need stuff like that. Right tool for the job, and all that
    • Still a young framework, and evolving. This is both good and bad. Bad, since the framework is changing while you code. Good, since it means that bugs (and maybe the above weaknesses, too) are getting fixed.

    So: it's not a silver bullet. Nothing is. But for a large majority of the modern-day web app use cases, it's very nice, productive and, well, elegant. It lets you to do quick prototypes and keep your code clean, you don't end up with the insecure and ugly mess most PHP apps end up being.

    • The lack of Unicode support isn't such a major deal. Most applications developed in Rails just push information around from database to user and vice versa without needing to 'do' much with it. Unicode will 'go through' a Rails application just fine. It's not as if your non ASCII text will suddenly disappear or get changed (unless your logic sets out to do this).
    • Well rails is a very good framework + toolset, but like every other enforcing toolset which tries to cover a lot of ground by automating stuff it has a huge problem, follow the road and you are set, if you cannot follow the road you are screwed. That is pretty much the problem with all toolsets which give you a lot of expert automation. A perfect example for this in the java world is maven, an excellent tool, but even the maven documentation says, use the structures provided by maven otherwise you will have

      • Re:Rails rocks (but isn't a silver bullet) (Score:4, Informative)

        by revscat ( 35618 ) on Wednesday March 08, 2006 @11:46AM (#14875366) Journal

        Well rails is a very good framework + toolset, but like every other enforcing toolset which tries to cover a lot of ground by automating stuff it has a huge problem, follow the road and you are set, if you cannot follow the road you are screwed.

        I have seen this complaint lodged many times, and at first I was concerned about it because of this, but I have yet to actually run into it. Rails is flexible enough that all the conventions it uses are overridable, and if you know of any exceptions to this please let me know, because I am still evaluating it. For example: by default AR assumes your primary key column is named id, but you can override that per-table if you like, or globally via environment.rb:

        ActiveRecord::Base.primary_key_prefix_type = :table_name_with_underscore

        Similarly, while AR expects plural table names, you can override that with the following:

        ActiveRecord::Base.pluralize_table_names = false

        So I don't agree with the (overly stated, IMHO) belief that Rails falls on its face when you move outside its conventions. My experience does not match this.

    • Re:Rails rocks (but isn't a silver bullet) (Score:4, Informative)

      by consumer ( 9588 ) on Wednesday March 08, 2006 @10:04AM (#14874420)
      I don't know about Python, but Perl and more recent versions of PHP are not interpreted. They are compiled to opcodes and then the opcodes are executed. With a persistent environment like mod_perl, you are always running the compiled code after the inital load. Both of them have much better base language performance than Ruby does at this point. I expect that Ruby will eventually work this way too.

      • I don't know about Python, but Perl and more recent versions of PHP are not interpreted. They are compiled to opcodes and then the opcodes are executed.

        Have you ever considered how those opcodes are executed? I assure you that in the common case the generated opcodes are not native instructions for your CPU.

        If by interpreted you mean, "parsing each line of code as it's needed" and by not interpreted you mean "on startup compiling the code to an intermediate representation that is more efficient", I sup

  • Now, if he could apply the same wisdom to SQL, etc (Score:3, Insightful)

    by expro ( 597113 ) on Wednesday March 08, 2006 @07:07AM (#14873751)
    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.

    • Re:Now, if he could apply the same wisdom to SQL, (Score:4, Interesting)

      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.
      • Well lets say it that way, I have been using hibernate for quite a while and it has a lots of quirks, the most annoying aspects of it, for many is: a) many to many mappings which simply need more documentation, the best way to do is is to enforce surrogates on the many to many tables otherwise you will often run into implicit clashes via compound keying (rails already enforces it, hibernate does not, it is not documented but after many hours of trying to fix this problem on a compound key I came to the conc
        • JPA, Hibernate etc... are very powerful apis, but they are way to complex for a RAD approach and they all have huge areas where they need to be cleaned up instead of being carried over to the next API. The biggest one of them IMHO are the areas mentioned.

          Good post, but I would disagree with some points. I don't think Hibernate is the easiest API - I far prefer JDO. Secondly, you don't have to use all that locking or use of lazy objects - you can use it in a very simple manner. The use of those features i
          • You bring up a point here with using something else, until recently Hibernate was the only OSS based implementation of an ORM system usable and coming close to being a standard and having good tools, now that JPA is out, we have finally a good number of them all based on JPA:

            Hibernate, KODO JPA, Toplink JPA all OSS based on various licenses. Due to the issues mentioned I will probably move away from Hibernate towards something else.

            The main problem with Kodo simply used to be the price which was way t
            • Due to the issues mentioned I will probably move away from Hibernate towards something else.

              I use a JDO product (Kodo) for very large transactions (hundreds of thousands of records), and it works very well and fast. Hibernate was, according to the developers, not intended for this sort of use - which I interpreted as a coded way of saying 'it is too hard to run write our stuff to run efficiently like that and we aren't bothering' :)

              Hibernate is extremely popular, but, in opinion, far from the best. The Ko
              • 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
  • 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

    • 1) it seems to mirror tables pretty directly;

      Well, that's how most people tend to code on top of databases. I'm sure you can point to lots of great examples as to how this is bad, so fire away.

      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.

      Great, because your model objects that use ActiveRecord don't know how they're stored in the database, either, short o
  • Most of the quick tutorials you see on the Internet don't use Migration. I think it's a lot better to go that way than to write a bunch of .sql files -- it allows you to switch database engines without worrying about the inconsistencies in the SQL between them and its rollback functionality is very useful.

    People just getting in to rails and ruby are not likely to have done more than scratched the surface of what ActiveRecord is capable of. This is a great introductory article, but I'm curious just how far

    • Even better, if you use something like DeZign for Databases, a database-neutral ERD program, it's pretty easy to switch your table schema from one database system to another (stored procs, triggers, etc. are not translated, however...)

      People keep talking about this, but be honest: how often does it happen in practice? Not too often.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close