Discussions

News: GenAndRun 0.1, another project like Rails, released

  1. GenAndRun 0.1 has been released. GenAndRun is another project in the mold of Ruby on Rails, attempting to allow developers to focus on the business logic and the look and feel of the application and let GenAndRun generates the code for most of the common cases for ORM and controller requirements.

    GenAndRun mainly uses the database metadata to generate the code, which is how it differs from Trails (model driven) and Sails (test driven), and how it resembles Rails (which also uses the database to manage the initial models).

    The project is looking for developers to help it along, both with requirements and code. Any takers?

    Threaded Messages (61)

  2. Any takers?

    Not me. Firstly, having a website with sections labelled
    'User Giude' and 'Documnetation' does not inspire confidence. Secondly, even Rails (as of version 1.0) is (fortunately) moving slighly away from purely 'table driven development' (with the introduction of 'schema.rb'). In my view the only sensible way forward is to allow full-featured two-way interactions between schemas and classes. There are already good tools out there to do this for a wide range of databases and stores which can be integrated into automated build scripts (such as Kodo's mapping and reverse mapping tools). Why should we step backwards to the limitations of Rails in this regard?
  3. <quote>In November 2002, Xenium acquired the business of EBU of Powerlan (HK) Limited and obtain most of the intellectual property rights of software products and solutions of Powerlan (HK) Limited.

    In December 2002, Xenium acquired the Intellectual property right of Oboweb DCM, an industry leading web content management system.</quote>

    Honestly, I will stand clear of contributing with a company who has interest in acquiring intellectual properties.
  4. table driven

    Horror!
    Generating code from a simple specification is a good idea, but
    Relational database are so ugly,
    Java classes are so nice,
    business component are so beautiful.

    Javier Paniza
    www.openxava.org
  5. Relational database are so ugly

    You must be joking, right? RDB are one of the best inventions in IT history.
  6. Beauty and Value are not mutually exclusive. Nor are they mutually inclusive. Also, beauty is in the eye of the beholder.
  7. Relational database are so ugly
    You must be joking, right? RDB are one of the best inventions in IT history.
    I totally agree that RDB are one of the best inventions in IT history.

    chris tam
    xenium
  8. Relational database are so ugly
    You must be joking, right? RDB are one of the best inventions in IT history.
    I totally agree that RDB are one of the best inventions in IT history.chris tamxenium

    I don't think the poster thinks RDBMS's are bad.

    But think about this: Lets say the business requirement is to "find all Members who are Male and are not deceased". Think about the many ways this could be implemented and coded in SQL/RDBMS and what, besides these basic requirements, is needed to be known to come up with the correct implementation. And then think about the (for instance) HQL version would be no matter what the RDMBS implementation is.
  9. Relational database are so ugly
    You must be joking, right? RDB are one of the best inventions in IT history.
    I totally agree that RDB are one of the best inventions in IT history.chris tamxenium
    I don't think the poster thinks RDBMS's are bad. But think about this: Lets say the business requirement is to "find all Members who are Male and are not deceased". Think about the many ways this could be implemented and coded in SQL/RDBMS and what, besides these basic requirements, is needed to be known to come up with the correct implementation. And then think about the (for instance) HQL version would be no matter what the RDMBS implementation is.
    As long as you don't have to calculate average number of male which last month applied for new category of product. Then RDBMS become wery useful with speed of calculation. ;-)
  10. Relational database are so ugly
    You must be joking, right? RDB are one of the best inventions in IT history.

    He drink too much Sun Kewl Ayde
  11. Relational database are so ugly
    You must be joking, right? RDB are one of the best inventions in IT history.
    He drink too much Sun Kewl Ayde

    Sigh. Unlike what grandma says - Pretty is NOT as Pretty does. (for those of you who don't know how to google - http://idioms.thefreedictionary.com/Pretty+is+as+pretty+does)
  12. Everything is RoR-a like?[ Go to top ]

    I have to laugh that any project which purports to try to help with productivity is "like Ruby on Rails" :)

    Rails != codegen

    Dion Almaer
    Founder, Ajaxian.com
    http://ajaxian.com
    Cleaning up the web with Ajax
  13. Everything is RoR-a like?[ Go to top ]

    I agree with Dion that Rails != Codegen. I think the point that a lot of people in the Java community miss is that the point of Rails is, quite simply, higher productivity throughout the development/maintenance lifecycle. Rails acheives this by focusing (at least for now it seams) on a particular application-type: the web front end for a single database.

    Code gen is merely a part of it. Having sensible defaults in almost every category is another. Having a standardized project layout that is compact and easy to navigate is another. The list goes on. I don't think Rails has a single killer feature (code gen isn't it), but that the package put together enables great productivity for a certain set of use cases.

    Given the dynamic nature of Ruby (and Rails) I think Java frameworks that try to tackle Rails on it's home turf will fail - Rails already has the mindshare and is pretty damn good. Where Java really has the advantage now is when we ramp up the difficulty of the problem. Need internationalization? No problem. Integrate with 5 vendors? Sure. Integrate with odd legacy schemas? Hibernate to the rescue.

    I think the Java community needs to start asking the same questions the Rails camp appears to have asked. What do we spend a lot of time doing? How can we reduce that time? The questions are the same, but the answers in the Java space may be quite different.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  14. Everything is RoR-a like?[ Go to top ]

    Given the dynamic nature of Ruby (and Rails) I think Java frameworks that try to tackle Rails on it's home turf will fail - Rails already has the mindshare and is pretty damn good.

    I am not sure I agree. With a lightweight web server framework, surely Java code could be generated and re-compiled and an application re-started in a few seconds - after all, JSPs work like this.

    As for mindshare - I am not convinced. Rails certainly has the publicity, but I have yet to see any real evidence of a mass movement to Rails use.
  15. Everything is RoR-a like?[ Go to top ]

    I am not sure I agree. With a lightweight web server framework, surely Java code could be generated and re-compiled and an application re-started in a few seconds - after all, JSPs work like this.As for mindshare - I am not convinced. Rails certainly has the publicity, but I have yet to see any real evidence of a mass movement to Rails use.

    Steve: I think Java could get close to the cycle time of Ruby/Rails, but it'll take work. The more I've been thinking about Rails the more I agree with Geert Bevin that hot-redeploy is increasingly important. When I can incrementally compile and deploy one hibernate class with mapping, one action and one JSP and use the updated artifacts without destroying my session etc. I think the gap will be closed "enough".

    I agree with your point about publicity vs. mindshare. I think there are a lot of factors at play, but I'm becoming convinced that Rails will be hard to beat for the small to medium web-site-in-front-of-db site. I'm very much unconvinced of it's ability to scale (as features are added) to larger more complex applications _and_ retain the productivity advantage. There will always be shops that would rather build everything in Java rather than have a mix of technologies, but where I think the Java community should focus is on ramping up the productivity when building medium to large, complex applications.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  16. Everything is RoR-a like?[ Go to top ]

    The more I've been thinking about Rails the more I agree with Geert Bevin that hot-redeploy is increasingly important.

    Absolutely.
    I think there are a lot of factors at play, but I'm becoming convinced that Rails will be hard to beat for the small to medium web-site-in-front-of-db site.

    Perhaps, although I can imagine that PHP will not lose ground without a fight, and I would suspect that Python would try and occupy that ground too. After all, the way that Rails works is easily transferred to other dynamic languages.

    I also think there is the possibility that tools such as Studio Creator may take off for the development of smaller sites. It is a very fast way to get designs up and running.
    I'm very much unconvinced of it's ability to scale (as features are added) to larger more complex applications _and_ retain the productivity advantage.

    Me too.
    There will always be shops that would rather build everything in Java rather than have a mix of technologies, but where I think the Java community should focus is on ramping up the productivity when building medium to large, complex applications

    Perhaps. However, I am not entirely sure that the actual productivity of coding is that important for such applications.
  17. Everything is RoR-a like?[ Go to top ]

    Perhaps, although I can imagine that PHP will not lose ground without a fight
    Agreed. Anyone dismissing PHP as a toy that doesn't scale is in for a rude awakening.

    The truth is that PHP is good enough for easily 90% of Web applications out there and it is very accessible to programmers with little CS background.

    Whether your own preferred Web framework (RoR or other) can scale better or is easier to use doesn't make the slightest difference if

    - You can't convince PHP users that it's better and easier than PHP
    - It doesn't get wide support from ISP's

    For the record, RoR isn't supported by my ISP but I can still write RoR applications using a local .htaccess. Still: I didn't go far because the Ruby processes were killed as soon as they started because they consumed too much memory. And my ISP is very flexible and usually lets its users go beyond their cap as long as it's reasonable.

    David did a fantastic job with RoR, but whether it will become mainstream or not is out of David's hands. And I predict it's going to be an uphill battle.

    --
    Cedric
  18. Everything is RoR-a like?[ Go to top ]

    I think the Java community needs to start asking the same questions the Rails camp appears to have asked. What do we spend a lot of time doing? How can we reduce that time? The questions are the same, but the answers in the Java space may be quite different.-Tim Fennell.
    Tim Fennell has already pointed out the lesson we have learn from RoR.<br> GenAndRun target no. 1 is: let java programmer spend less time on those simple and common tasks like writing and updating those set/get methods and xml for simple database access requirements.<br> GenAndRun target no. 2: java programmers do not need to spend time to learn GenAndRun framework or api in order to customize the generated application. The generated application should be only a normal Spring application.
  19. Everything is RoR-a like?[ Go to top ]

    This is an interesting discussion. I think that some commentators are missing the point of Rails. It's about code generation! No, it's about hot-deploy! No, it's about convention over configuration! I think it's about all of these things, but these things are easier to do in a dynamic language like Ruby.

    As Dion notes, developers who think Rails is all about traditional code generation are missing the point completely. Even the name of this new framework (GenAndRun) seems to miss this point. Yes, Rails scaffolds are traditional code generators, and they're kind of cute, and you should be able to do something similar in Java as well. But the dynamic 'generation' that ActiveRecord does is basically impossible in Java. There's other similar magic going on elsewhere in Rails. And you just can't do that sort of thing in a less dynamic language like Java. That's why I think frameworks that try to recreate Rails in Java will never be as nice as Rails.

    Other commentators are essentially arguing that you shouldn't do this kind of dynamic method generation. Or at least you shouldn't generate methods from table columns. That would be 'table driven design', which is bad. I have to admit this was my initial reaction as well. Here too I think there's some confusion. Java developers seem to imagine that Rails generates source code for complete model classes from the database schema, the same way the Hibernate schema to class generator does. But that's not quite how it works. When I work in Rails, I use test driven design, which helps me defines the API for my domain objects. I define behavior methods in the source file for my domain object. I define persistent attributes in the SQL schema. Rails dynamically adds methods for these columns to the model object. If I need a value object, I define an aggregate. Yes in this case I may need to specify mapping information in the source file. But I do that only when needed.

    Is it awkward to have to flip back and forth between two files, the source code and the schema? Yes, a little. But it also avoids unnecessary duplication. It's a trade-off. You may like it, you may not. But is this 'table driven design'? Not really.

    I tend to agree with the commentator who said that PHP is best for small apps, Rails for medium sized web apps that talk to one database, and Java for more complicated apps. Although I would qualify it slightly -- there are different kinds of complexity. Apps that talk to just one database can be quite complicated in other respects, and Rails might still be a good fit. Ruby's ability to easily create DSLs and reduce the amount of code required could still be important for these kinds of apps. But then again maybe you need better refactoring support for tehse large apps, which Ruby doesn't really provide. Conversely, an app that's a fairly simple integrator or front-end legacy systems might need XA transactions, JMS, and the like, features that Rails doesn't (yet) provide. And of course you can always mix and match languages. But again my point is that there are different kinds of complexity which may be best solved with different kinds of tools.

    Other commentators note that hot-deploy is really important. That's true, and who knows maybe hot-deploy in Java will someday live up to its promise. That's still only part of the puzzle. Things like convention over configuration are easier to implement in a dynamic language, because of the better reflection, dynamic class and method generation capabilities.

    I could go on. But I think attempting to make a Rails look-a-like in Java is doomed to failure. Ruby is Ruby, Java is Java, and they have different strengths and weaknesses.

    Steve
  20. Everything is RoR-a like?[ Go to top ]

    This is an interesting discussion....But I think attempting to make a Rails look-a-like in Java is doomed to failure. Ruby is Ruby, Java is Java, and they have different strengths and weaknesses.Steve

    I still think that a Rails-type thing is possible; if not in Java itself, then in some Java-based language or approach like JSPs, or Groovy. However, I am far from convinced that much of the current Rails approach is a good idea, so I am not sure how useful copying it is going to be. Dynamically generating classes from tables and convention over configuration seem to me to have a certain fragility about them - in larger apps if things go wrong, my feeling is that problems could be hard to trace. I think that there is an atmosphere of 'too clever-ness' about Rails, where things are done because they are cool and fun and look really neat, rather than because they form the basis of a robust and reliable approach to application design.

    I am going to be foolish and make a prediction - that as Rails matures, it will start to gain some of the 'baggage' associated with larger frameworks like J2EE, because this 'baggage' will be found to be a useful part of creating a robust scalable system.

    For example, I would not be surprised to see, in a year or several, some sort of portable query language as an alternative to native SQL in Rails.
  21. Everything is RoR-a like?[ Go to top ]

    Dynamically generating classes from tables and convention over configuration seem to me to have a certain fragility about them - in larger apps if things go wrong, my feeling is that problems could be hard to trace.

    Technically Rails doesn't generate classes from tables; rather it dynamically adds methods to existing classes. A slight distinction perhaps, but Rails isn't quite as loosey-goosey as some might think. It is very rigourous about enforcing the DRY (don't repeat yourself) principle. That's what dynamically adding methods from schema and convention over configuration are all about -- specify things in exactly one place; only configure exceptions to conventions. Rails also makes it fairly easy to write good automated tests. Rails has a different kind of discipline perhaps, but it's still very disciplined.
  22. Everything is RoR-a like?[ Go to top ]

    I still think that a Rails-type thing is possible; if not in Java itself, then in some Java-based language or approach like JSPs, or Groovy.

    Well, I'm not sure I'd want a JSP based ORM tool. ;) But yes, theoretically you could do a Rails clone in something like Groovy if you really wanted to. There are already some Python Rails-like frameworks. Ruby works particulary well for this sort of thing but it should be possible in many dynamic languages. Not really pratical in a more static language like Java though.
    I am going to be foolish and make a prediction - that as Rails matures, it will start to gain some of the 'baggage' associated with larger frameworks like J2EE, because this 'baggage' will be found to be a useful part of creating a robust scalable system. For example, I would not be surprised to see, in a year or several, some sort of portable query language as an alternative to native SQL in Rails.

    That could be. As the Rails folks would readily admit, there are many useful features missing in Rails: XA tranasctions, a JMS like solution, multi-table inheritance mapping, etc. None of those features are incompatible with Rails' basic approach, and adding those features wouldn't turn Rails into a J2EE clone. It would still be different (love it or hate it).
  23. Everything is RoR-a like?[ Go to top ]

    As the Rails folks would readily admit, there are many useful features missing in Rails

    It is my impression that although there are things missing from Rails, there is an attitude associated with Rails that if it doesn't include something, then it isn't really that useful, and it only included in supposedly 'over-engineered' alternatives. I have tried to discuss portable query languages with some Rails advocates only to get the response that 'a minimal portable subset of SQL should be enough for almost anyone', and 'well I've' never had any problem with portability'. I have seen this sort of attitude before - from MySQL people when it was pointed out that (at least until recently) MySQL was missing features such as subselects.

    This is one of the reasons I am hesitant to use Rails.
  24. Everything is RoR-a like?[ Go to top ]

    It is my impression that although there are things missing from Rails, there is an attitude associated with Rails that if it doesn't include something, then it isn't really that useful, and it only included in supposedly 'over-engineered' alternatives. I have tried to discuss portable query languages with some Rails advocates only to get the response that 'a minimal portable subset of SQL should be enough for almost anyone', and 'well I've' never had any problem with portability'. I have seen this sort of attitude before - from MySQL people when it was pointed out that (at least until recently) MySQL was missing features such as subselects.This is one of the reasons I am hesitant to use Rails.
  25. Everything is RoR-a like?[ Go to top ]

    Sorry about the empty post. Let's try this again:
    It is my impression that although there are things missing from Rails, there is an attitude associated with Rails that if it doesn't include something, then it isn't really that useful, and it only included in supposedly 'over-engineered' alternatives. I have tried to discuss portable query languages with some Rails advocates only to get the response that 'a minimal portable subset of SQL should be enough for almost anyone', and 'well I've' never had any problem with portability'. I have seen this sort of attitude before - from MySQL people when it was pointed out that (at least until recently) MySQL was missing features such as subselects.This is one of the reasons I am hesitant to use Rails.

    Well it's hard to argue with impressions. I'm defending the Rails framework itself, not everything that's ever been said about it. But my impression at least is that the community isn't always that smug or monolithic. A few examples:

    XA Transactions: In the 'Agile Development with Rails' book (co-written by the creator of Rails), they explicitly state XA transactions are useful, that Rails doesn't support XA transaction yet, and that if you need to talk to multiple databases you probably shouldn't use Rails at this time.

    ORM: OK on this one I'm talking more about the Ruby community in general, not just Rails. There's an alternative to ActiveRecord (Rails' ORM solution) called Og. Apparently Og takes an more 'model driven' approach similar to Hibernate. It's sometimes discussed as an alternative to ActiveRecord. I really don't know much about Og but I plan to look into it. My point is that folks do realize that there's more than one way to solve a problem, and things aren't that monolithic. You have options.

    Portable Query Language: OK, this is a hot topic! Obviously anyone who says portability doesn't matter or isn't an issue is either ignorant or stupid, so we can just ignore them. But I'd like to make two points:

    1. Portability vs. power is often a compromise. For example Hibernate 2 HQL is not 100% portable. I know, I recently finished porting a large Hibernate 2 based app from Informix to Oracle. In your HQL queries, you can do things like 'select upper(foo.blah) from Foo where column_name = custom_sql_function(?)'. Hibernate will pass the upper function, the column_name, and the custom_sql_function straight through to generated SQL. And it will work. But it's not portable. Is this a poor design on Hibernate's part? Well, it's a tradeoff. Leaky abstractions can be useful. It's sometimes handy to call an SQL function in your HQL. But it's not always portable. So is this a defect or a feature? Hibernate touts it as a feature. Does that make the Hibernate folks a bunch of raving idiots, or just engineers who made a trade-off and defended it?

    The documentation for ActiveRecord encourages you not to use SQL except where necessary. Instead the prefered way is to either use the query methods that ActiveRecord generates (and which are portable), or to use ActiveRecord's equivalent of the Hibernate Criteria API (well, sort of equivalent) which does take SQL snippets for the where clause and the like. These snippets are not necessarily portable, similar to the where clause in HQL queries. But you're not hand coding the complete query.

    2. A secondary issue is really about style. Would you rather have a portable query language that looked object-oriented, or that looked like a portable dialect of SQL? Pros and cons here, but that's a separate issue than portability.
  26. Everything is RoR-a like?[ Go to top ]

    1. Portability vs. power is often a compromise. For example Hibernate 2 HQL is not 100% portable. I know, I recently finished porting a large Hibernate 2 based app from Informix to Oracle. In your HQL queries, you can do things like 'select upper(foo.blah) from Foo where column_name = custom_sql_function(?)'. Hibernate will pass the upper function, the column_name, and the custom_sql_function straight through to generated SQL. And it will work. But it's not portable. Is this a poor design on Hibernate's part? Well, it's a tradeoff. Leaky abstractions can be useful. It's sometimes handy to call an SQL function in your HQL. But it's not always portable. So is this a defect or a feature? Hibernate touts it as a feature. Does that make the Hibernate folks a bunch of raving idiots, or just engineers who made a trade-off and defended it?

    Well, we moved a fairly large app from Oracle to SQL Server and hibernate in its entirety was portable requiring only the Dialect change. The only thing converted were things like the use of Oracles 'Decode' functions.

    I guess my question is if it did work, how was it *not* portable? I can see if it didn't work...
  27. Everything is RoR-a like?[ Go to top ]

    A big one was the function that returns the current time bit us. It's 'today' in Informix but 'sysdate' in Oracle. Not a big deal, but just an example of where it's not 100% portable. In theory you could call any SQL function in HQL. But yes, most SQL functions one calls in HSQL, like 'upper', are implemented the same in virtually every SQL dialect. But in that case it's portable because that aspect of SQL is portable, not because of HQL. Is HQL 100% portable? No. Does that matter? Depends. Ditto for ActiveRecord.
  28. Everything is RoR-a like?[ Go to top ]

    Is HQL 100% portable? No. Does that matter? Depends. Ditto for ActiveRecord.

    No, it is not the same for ActiveRecord. There is all the difference between an approach that attempts to give as much portability in query languages as possible (but allows use of native SQL where it is really needed) and one that abandons any attempt to give query language portability at all.
  29. Everything is RoR-a like?[ Go to top ]

    <blockquoteNo, it is not the same for ActiveRecord. There is all the difference between an approach that attempts to give as much portability in query languages as possible (but allows use of native SQL where it is really needed) and one that abandons any attempt to give query language portability at all.
    Steve

    I know what you're saying. There would be some benefit to a portable query language in ActiveRecord. And I agree, I could imagine them implementing one at some point. I think where we disagree is how much importance to attach to this. In practice I don't find myself writing much custom SQL in Rails, as I let the generated query methods and relations do stuff for me. And where I do use SQL I try to stick to stuff I think is portable. The amount of potentially unportable code is not that great. Conversely even in Hibernate it's possible to sneak in unportable code without developers being immediately aware of it. So in practice, I'm not sure that porting a Rails app to a different database would be *that* much more difficult than porting a Hibernate app. (I'm waiting for you to jump on that statement! ;) )

    But I'm just curious: There seems to be two camps in the "we don't need no stinking Rails" crowd. (Well actually 3, counting those who haven't really investigated and have never used Rails.)

    One camp dismisses dynamic languages entirely. Been there, done that with Smalltalk and Lisp. They didn't catch on, Ruby won't either. They don't scale. Refactoring is hard (well, not in Smalltalk). We need static type checking to protect developers from themseves. Etc. This camp would logically not have much use for Groovy either, expect for minor scripty stuff.

    The second camp likes or is at least open to dynamic languages, but doesn't like certain aspects of Rails. The biggest one is ActiveRecord and it's dirty SQL. I find this second camp more interesting personally. I'm sold on Ruby, and Rails in general, but that doesn't mean I'm in love with each and every detail of it.

    Which camp are you in?

    Steve
  30. Everything is RoR-a like?[ Go to top ]

    The second camp likes or is at least open to dynamic languages, but doesn't like certain aspects of Rails.

    That is me.
    The biggest one is ActiveRecord and it's dirty SQL.

    It is not the 'dirty SQL' aspect that I dislike most (I don't think that SQL is dirty - simply not very portable) it is the 'define the data model as tables' part that really seems so wrong to me. Portability is an important part of almost every application I now write, and tying my application down even to relying on relational databases as the only way to persist my data seems the wrong way to go. Even when I do use relational systems, I want to be able to move my application easily between them, while using each one to the full. ActiveRecord seems to me to be a database vendors dream - have developers start their design from the database (with all the possibilities for vendor extensions and product-specific column types that this can involve) and work up from there. In the Java world we have been working hard to free ourselves from such lock-in for years. ActiveRecord seems a big step backwards.
  31. Everything is RoR-a like?[ Go to top ]

    It is not the 'dirty SQL' aspect that I dislike most (I don't think that SQL is dirty - simply not very portable) it is the 'define the data model as tables' part that really seems so wrong to me. Portability is an important part of almost every application I now write, and tying my application down even to relying on relational databases as the only way to persist my data seems the wrong way to go. Even when I do use relational systems, I want to be able to move my application easily between them, while using each one to the full. ActiveRecord seems to me to be a database vendors dream - have developers start their design from the database (with all the possibilities for vendor extensions and product-specific column types that this can involve) and work up from there. In the Java world we have been working hard to free ourselves from such lock-in for years. ActiveRecord seems a big step backwards.

    I think ActiveRecord and Java ORMs like Hibernate have different goals. And ActiveRecord is doing things that aren't possible in Java, thus it's hard for Java developers to understand the benefits of ActiveRecords approach initially. Hibernate strives to completely encapsulate the database. ActiveRecord tries to eliminate duplication. Both are worthwhile goals.

    With ActiveRecord the attributes of an object are defined in exactly one place -- the schema. It does this by dynamically injected methods into objects based on the column definitions. This may feel wrong to you, but it really helps eliminate duplication and clutter. This is important for maintainability. Now one might think, we've been through years of gyrations in the Java space wiith ORM technology, we've learned all there is to learn in that space, anything that doesn't follow Java best practices must be a step backwards. But what ActiveRecord is doing has never been done in Java, because you can't do it. You kind of have to try it for a little while to appreciate it.

    Anyway I've enjoyed bantering with you and respect your opinion. We'll probably just have to agree to disagree on this one!

    Steve
  32. Everything is RoR-a like?[ Go to top ]

    With ActiveRecord the attributes of an object are defined in exactly one place -- the schema. It does this by dynamically injected methods into objects based on the column definitions. This may feel wrong to you, but it really helps eliminate duplication and clutter. This is important for maintainability.

    I don't think it is. Duplication and clutter can also be prevented by having objects defined in exactly one place - the object model. There are well-established mechanisms for keeping the database schema in synchronisation with the object model (I use JDO tools that have ant tasks to automate this). At any given time the definitions may exist in more than one place, but but changes are only made in one.

    Actually, ActiveRecord does not solve this problem, as code that does anything much more than the basic scaffolding will explicitly mention column names in various places. If changes are made to the schema, these uses of the column names will need to be located so that code can be updated to reflect these changes. If the data model were defined in ruby code then changes could be made to the model and tests performed on these changes away from the database, with ActiveRecord (at least as I understand it), they can't.

    With the Java ORM I use things are even easier - refactoring tools and the compiler will locate the consequences of many changes in the data model. When these have been dealt with an ant task updates the schema. I can easily and confidently run tests of the new data model on a different (lightweight) database that is not the deployment (commercial) database. I can be confident of such tests because the model is represented as the same Java source when I switch databases. In ActiveRecord, the definition of the model will be almost inevitably be represented by different DDL on different platforms.
    But what ActiveRecord is doing has never been done in Java, because you can't do it.

    My opinion is that having the classes representing the database dynamically generated at runtime is fun and showy, but potentially makes things far more difficult to maintain, not easier. There is no reason why ActiveRecord could not have generated ruby source files which represent the schema, and these source files could be automatically kept up to date. This approach would potentially allow all sorts of code analysis and refactoring that are impossible with the 'cool' dynamic approach. Actually, I believe something like this is possible in Rails 1.0.
    You kind of have to try it for a little while to appreciate it.

    This sounds like the 'if you don't like it you don't understand it yet' attitude I have often heard from Rails enthusiasts. It sounds condescending (even if true :)
    Now one might think, we've been through years of gyrations in the Java space wiith ORM technology, we've learned all there is to learn in that space, anything that doesn't follow Java best practices must be a step backwards.

    What I am talking about is not Java best practices - ORM systems where the data model is primarily defined as objects, not tables, have been around for a long time in various languages.

    Although ORM can seem a bit awkward - mapping object interactions and relationships to an RDBMS can be complex - designing a data model for an OOP language primarily in terms of database tables would seem to be very limiting.
    Anyway I've enjoyed bantering with you and respect your opinion. We'll probably just have to agree to disagree on this one!Steve

    Fair enough!
  33. Everything is RoR-a like?[ Go to top ]

    <Although ORM can seem a bit awkward - mapping object interactions and relationships to an RDBMS can be complex - designing a data model for an OOP language primarily in terms of database tables would seem to be very limiting.
    This is a very big point. Some choose to believe/ignore that the data model and the object model are different and have different needs. That is why ORMs are so useful and might take a step back in the (DRY) maintenance part (but as you have shown, not always), but take steps forword in other maintenance areas.

    The app I am working on is not yet in production, but we have changed the underlying data model a few times, but not the object model. The dba/dm didn't like some column names. No problem. We discovered that some relationships should be in associative tables in the db. No problem. And oddly, we did a model first design.

    What I see is that when comparing RoR to Java (or .Net to Java or ...) the whole picture is not taken into account. If one takes a few things from each and compares them, then sure, RoR is tons better. "RoR is good for web apps connecting to a single db". Well, I don't do that. I have apps that might be persisted in a RDBMS (today) and might have a web ui and/or a non-browser ui and/or talk to other apps/systems. Sadly, I am not clairvoyant and don't know what the future is for my apps. So I like to hedge my bets. It is usually good that I did.

    I am with you Steve. I want to like RoR. But I have some issues from lessons learned in the past.

    I do have issues with Ruby too. I can't easily type @. :) So any language that forces me to type a lot of odd characters makes me instantly less productive.
  34. Everything is RoR-a like?[ Go to top ]

    But what ActiveRecord is doing has never been done in Java, because you can't do it.

    I don't think:
    1) take one of many instrumentation libraries out of there
    2) write a classloader (or an equivalent based on the chosen library) that reads database metadata
    3) weave your ActiveRecord-like Java classes

    Ciao and happy new year,
    Diego
  35. Everything is RoR-a like?[ Go to top ]

    A big one was the function that returns the current time bit us. It's 'today' in Informix but 'sysdate' in Oracle. Not a big deal, but just an example of where it's not 100% portable. In theory you could call any SQL function in HQL. But yes, most SQL functions one calls in HSQL, like 'upper', are implemented the same in virtually every SQL dialect. But in that case it's portable because that aspect of SQL is portable, not because of HQL. Is HQL 100% portable? No. Does that matter? Depends. Ditto for ActiveRecord.

    I missed the function call in your original example, but so far the only thing you've offered are two examples where your developes *choose* to use non-portable calls.

    In this case, your portability issues are caused by how you *chose* to use Hibernate, and not Hibernate.
  36. Everything is RoR-a like?[ Go to top ]

    ...but so far the only thing you've offered are two examples where your developes *choose* to use non-portable calls.In this case, your portability issues are caused by how you *chose* to use Hibernate, and not Hibernate.

    True. But it's not immediately apparent to developers which bits in an HQL query are generic HQL, and which bits are ignored by the HQL parser and passed directly into the resulting SQL (and thus potentially non-portable). Take this HQL query:

    "select upper(foo.name) from Foo foo, left join fetch foo.bar bar where trim(name) = trim(?)"

    Quick, which bits are portable HQL, and which bits are potentially unportable SQL? Answer: upper, trim, and name in the where clause are potentially unportable. Upper and trim are SQL function calls, not HQL. The 'left join' bit, which looks kind of SQL-ish, is actually HQL, not SQL. 'name' in the where clause refers to a column called 'name', not a property name. It's probably a typo, the developer probably intended 'foo.name'. But it will 'work' if there's a column called 'name' somewhere in the query.

    Now of course upper and trim are implemented by virtually every RDMS on the planet, so you're pretty safe. But that assumes the developer knows which subset of SQL is portable. And if you rely on developers knowing which bits of SQL are portable, then you don't need another portable query language on top of SQL in the first place!

    Steve
  37. Everything is RoR-a like?[ Go to top ]

    ...but so far the only thing you've offered are two examples where your developes *choose* to use non-portable calls.In this case, your portability issues are caused by how you *chose* to use Hibernate, and not Hibernate.
    True. But it's not immediately apparent to developers which bits in an HQL query are generic HQL, and which bits are ignored by the HQL parser and passed directly into the resulting SQL (and thus potentially non-portable). Take this HQL query:"select upper(foo.name) from Foo foo, left join fetch foo.bar bar where trim(name) = trim(?)"Quick, which bits are portable HQL, and which bits are potentially unportable SQL? Answer: upper, trim, and name in the where clause are potentially unportable. Upper and trim are SQL function calls, not HQL. The 'left join' bit, which looks kind of SQL-ish, is actually HQL, not SQL. 'name' in the where clause refers to a column called 'name', not a property name. It's probably a typo, the developer probably intended 'foo.name'. But it will 'work' if there's a column called 'name' somewhere in the query.Now of course upper and trim are implemented by virtually every RDMS on the planet, so you're pretty safe. But that assumes the developer knows which subset of SQL is portable. And if you rely on developers knowing which bits of SQL are portable, then you don't need another portable query language on top of SQL in the first place! Steve

    But *you* choose to write it this way. That's like saying C isn't portable because you used Win32 api for an app that had to work on Unix. That developers cannot be blame because you chose to use something portable in a non-portable fashion. I would say that the problems you had was because of your usage, not the tool.
  38. Everything is RoR-a like?[ Go to top ]

    ...but so far the only thing you've offered are two examples where your developes *choose* to use non-portable calls.In this case, your portability issues are caused by how you *chose* to use Hibernate, and not Hibernate.
    True. But it's not immediately apparent to developers which bits in an HQL query are generic HQL, and which bits are ignored by the HQL parser and passed directly into the resulting SQL (and thus potentially non-portable). Take this HQL query:"select upper(foo.name) from Foo foo, left join fetch foo.bar bar where trim(name) = trim(?)"Quick, which bits are portable HQL, and which bits are potentially unportable SQL? Answer: upper, trim, and name in the where clause are potentially unportable. Upper and trim are SQL function calls, not HQL. The 'left join' bit, which looks kind of SQL-ish, is actually HQL, not SQL. 'name' in the where clause refers to a column called 'name', not a property name. It's probably a typo, the developer probably intended 'foo.name'. But it will 'work' if there's a column called 'name' somewhere in the query.Now of course upper and trim are implemented by virtually every RDMS on the planet, so you're pretty safe. But that assumes the developer knows which subset of SQL is portable. And if you rely on developers knowing which bits of SQL are portable, then you don't need another portable query language on top of SQL in the first place! Steve
    But *you* choose to write it this way. That's like saying C isn't portable because you used Win32 api for an app that had to work on Unix. That developers cannot be blame because you chose to use something portable in a non-portable fashion. I would say that the problems you had was because of your usage, not the tool.

    I heard you the first time. But I think you missed my point. I'm not saying you can't write portable code with HQL. You can. Heck, I can write portable code with ActiveRecord if I work hard at it. But point is that with HQL it's not explicit when you do non-portable stuff. It's not clear to developers that they are making a non-portable choice.

    With C, if I change my make file to put the Win32 headers in the include path, and explicitly include a Win32 header in a source file, and *then* make a win32 api call, then yes I'm writing non-portable code. But it's very clear. How I write my statements or expressions doesn't affect portability (usually), just what I explicitly include.

    With HQL, how you write your query affects its portability, in non-obvious ways. One word in the query might be portable, the next word not. And there's no flag (that I'm aware of) warning you.

    I'm not saying it's a huge deal. Arguably it's a feature. Just that it's not obvious. At least as of Hibernate 2, HQL is a very thin wrapper around SQL, which makes it easy to slide in actual SQL into your HQL without necessarily being aware of it.

    A totally portable query language wouldn't pass through anything it didn't understand, unless it was explicitly marked as non-portable in some way.

    Steve
  39. Everything is RoR-a like?[ Go to top ]

    ...but so far the only thing you've offered are two examples where your developes *choose* to use non-portable calls.In this case, your portability issues are caused by how you *chose* to use Hibernate, and not Hibernate.
    True. But it's not immediately apparent to developers which bits in an HQL query are generic HQL, and which bits are ignored by the HQL parser and passed directly into the resulting SQL (and thus potentially non-portable). Take this HQL query:"select upper(foo.name) from Foo foo, left join fetch foo.bar bar where trim(name) = trim(?)"Quick, which bits are portable HQL, and which bits are potentially unportable SQL? Answer: upper, trim, and name in the where clause are potentially unportable. Upper and trim are SQL function calls, not HQL. The 'left join' bit, which looks kind of SQL-ish, is actually HQL, not SQL. 'name' in the where clause refers to a column called 'name', not a property name. It's probably a typo, the developer probably intended 'foo.name'. But it will 'work' if there's a column called 'name' somewhere in the query.Now of course upper and trim are implemented by virtually every RDMS on the planet, so you're pretty safe. But that assumes the developer knows which subset of SQL is portable. And if you rely on developers knowing which bits of SQL are portable, then you don't need another portable query language on top of SQL in the first place! Steve
    But *you* choose to write it this way. That's like saying C isn't portable because you used Win32 api for an app that had to work on Unix. That developers cannot be blame because you chose to use something portable in a non-portable fashion. I would say that the problems you had was because of your usage, not the tool.
    I heard you the first time. But I think you missed my point. I'm not saying you can't write portable code with HQL. You can. Heck, I can write portable code with ActiveRecord if I work hard at it. But point is that with HQL it's not explicit when you do non-portable stuff. It's not clear to developers that they are making a non-portable choice.With C, if I change my make file to put the Win32 headers in the include path, and explicitly include a Win32 header in a source file, and *then* make a win32 api call, then yes I'm writing non-portable code. But it's very clear. How I write my statements or expressions doesn't affect portability (usually), just what I explicitly include. With HQL, how you write your query affects its portability, in non-obvious ways. One word in the query might be portable, the next word not. And there's no flag (that I'm aware of) warning you.I'm not saying it's a huge deal. Arguably it's a feature. Just that it's not obvious. At least as of Hibernate 2, HQL is a very thin wrapper around SQL, which makes it easy to slide in actual SQL into your HQL without necessarily being aware of it. A totally portable query language wouldn't pass through anything it didn't understand, unless it was explicitly marked as non-portable in some way.Steve

    You have to include headers even if the code is portable so I don't agree with your take on that. My point is that the comparisions you presented between ActiveRecord and Hibernate HQL don't hold water...to me. It is no more work to use a non-portable call than portable one. It's up to the operator.

    You can write portable code with ActiveRecord if you work hard. I want to write portable code *without* the hard work.

    If I created a custom function on Oracle, I have no problem with HQL *not* complaining because I should have placed that same function on Sybase. I don't complain if my car allows me to drive above the posted speed limit.

    If you lose control at high speeds, its not the cars fault, but the driver.
  40. Everything is RoR-a like?[ Go to top ]

    I don't complain if my car allows me to drive above the posted speed limit. If you lose control at high speeds, its not the cars fault, but the driver.

    Unless the car doesn't provide a speedometer.
    You have to include headers even if the code is portable so I don't agree with your take on that.

    But surely you can see that '#include win32/blah.h' is more explicit and obvious than having to know how the HQL parser is implemented and having to know which keywords it passes directly through to HQL?

    You seem to be engaging in the same sort of defensiveness that others have criticized in Rails developers -- defending your favorite tool so hard that you can't even understand minor criticisms.
    If I created a custom function on Oracle, I have no problem with HQL *not* complaining because I should have placed that same function on Sybase.

    Yes but wouldn't it be nice if HQL let me know that I was doing something that wasn't portable? (And no, rewriting custom SQL functions for different databases isn't my definition of portable. And not all built-in SQL functions behave the same way on all RDMS.)
  41. Everything is RoR-a like?[ Go to top ]

    But surely you can see that '#include win32/blah.h' is more explicit and obvious than having to know how the HQL parser is implemented and having to know which keywords it passes directly through to HQL?

    Sorry, should read 'passes directly through to *SQL*'.
  42. Everything is RoR-a like?[ Go to top ]

    I don't complain if my car allows me to drive above the posted speed limit. If you lose control at high speeds, its not the cars fault, but the driver.
    Unless the car doesn't provide a speedometer.
    You have to include headers even if the code is portable so I don't agree with your take on that.
    But surely you can see that '#include win32/blah.h' is more explicit and obvious than having to know how the HQL parser is implemented and having to know which keywords it passes directly through to HQL? You seem to be engaging in the same sort of defensiveness that others have criticized in Rails developers -- defending your favorite tool so hard that you can't even understand minor criticisms.
    If I created a custom function on Oracle, I have no problem with HQL *not* complaining because I should have placed that same function on Sybase.
    Yes but wouldn't it be nice if HQL let me know that I was doing something that wasn't portable? (And no, rewriting custom SQL functions for different databases isn't my definition of portable. And not all built-in SQL functions behave the same way on all RDMS.)

    Include blah.h doesn't tell you if the code is portable or not. I'm sorry that you think I'm being defensive. I'm not. Hibernate does have flaws, but what you are calling a flaw is caused not by Hibernate, but the the user. I don't blame cars when the driver runs a red light and that is what you are doing.

    If you say
     - Hibernate should do a better job at outputing its SQL
     - Hibernate should do a better job at reporting errors in the mapping of class to table
     - Hibernate should provide better examples of how to use certain HQL functions

    for example, I'm with you. But if you say that HQL is flawed because your developers used non-portable calls, well, I just don't buy it.
  43. Everything is RoR-a like?[ Go to top ]

    A totally portable query language wouldn't pass through anything it didn't understand, unless it was explicitly marked as non-portable in some way.

    I you really want this, take a look at JDO 2.0 - it is very full featured, now has a standard O/R mapping (unlike JDO 1.0) and has a total portable query language that is far more than just a wrapper over SQL, and can run on non-relational stores as well as all the usual relational systems. If you want to use vendor-specific SQL (or another query language) in place of JDOQL, you have to explicitly indicate this.
  44. Everything is RoR-a like?[ Go to top ]

    If you really want this, take a look at JDO 2.0 - it is very full featured, now has a standard O/R mapping (unlike JDO 1.0) and has a total portable query language that is far more than just a wrapper over SQL, and can run on non-relational stores as well as all the usual relational systems. If you want to use vendor-specific SQL (or another query language) in place of JDOQL, you have to explicitly indicate this.

    Thanks, that was helpful. I'm not sure that I need this, but naturally it depends on the project. I can imagine that for some projects this would be important.
  45. Everything is RoR-a like?[ Go to top ]

    If you really want this, take a look at JDO 2.0 - it is very full featured, now has a standard O/R mapping (unlike JDO 1.0) and has a total portable query language that is far more than just a wrapper over SQL, and can run on non-relational stores as well as all the usual relational systems. If you want to use vendor-specific SQL (or another query language) in place of JDOQL, you have to explicitly indicate this.
    Thanks, that was helpful. I'm not sure that I need this, but naturally it depends on the project. I can imagine that for some projects this would be important.

    Many ORM vendors (and open source products) are providing both EJB 3.0 and JDO 2.0 implementations in the same product - usually allowing the use of both even at the same time in the same application (with all the current (understandable) emphasis on EJB 3.0, it is often forgotten that the JDO 2.0 API is now pretty similar in many ways, and has some advantages - it can be used on more than just relational stores and Java 5.0). I currently use Kodo and JPOX.
  46. Everything is RoR-a like?[ Go to top ]

    OK on this one I'm talking more about the Ruby community in general, not just Rails.

    I'm concentrating on Rails - as that is the framework that is generating the hype. I have lost count of the number of times a defence of RoR has, paradoxically, involved saying 'well, you can change abandon (or hack) ActiveRecord (one of the key parts of the framework'.
    Portable Query Language: ..... HQL is not 100% portable.... In your HQL queries, you can do things like 'select upper(foo.blah) from Foo where column_name = custom_sql_function(?)'.... So is this a defect or a feature? Hibernate touts it as a feature.

    I would say that of course it is not a defect - however if you use custom sql functions in portable query languages, then of course it isn't always going to be portable.
    Does that make the Hibernate folks a bunch of raving idiots, or just engineers who made a trade-off and defended it?

    I would say that you were the one making the trade-off by using the non-HQL function.
    The documentation for ActiveRecord encourages you not to use SQL except where necessary. Instead the prefered way is to either use the query methods that ActiveRecord generates (and which are portable), or to use ActiveRecord's equivalent of the Hibernate Criteria API (well, sort of equivalent) which does take SQL snippets for the where clause and the like. These snippets are not necessarily portable, similar to the where clause in HQL queries.

    It is not the same thing. You have rich additional methods to obtain objects apart from the direct use of query languages in all modern ORMs - Hibernate, JDO 2.0 etc. However, with these you also have the option of expressing complex queries portably (even when using databases that don't have that full an SQL implementation). With ActiveRecord the SQL you can use is totally limited by the underlying store.
    Would you rather have a portable query language that looked object-oriented, or that looked like a portable dialect of SQL? Pros and cons here, but that's a separate issue than portability.

    Indeed.
  47. Everything is RoR-a like?[ Go to top ]

    This is an interesting discussion....But I think attempting to make a Rails look-a-like in Java is doomed to failure. Ruby is Ruby, Java is Java, and they have different strengths and weaknesses.Steve
    I still think that a Rails-type thing is possible; if not in Java itself, then in some Java-based language or approach like JSPs, or Groovy. However, I am far from convinced that much of the current Rails approach is a good idea, so I am not sure how useful copying it is going to be. Dynamically generating classes from tables and convention over configuration seem to me to have a certain fragility about them - in larger apps if things go wrong, my feeling is that problems could be hard to trace. I think that there is an atmosphere of 'too clever-ness' about Rails, where things are done because they are cool and fun and look really neat, rather than because they form the basis of a robust and reliable approach to application design.I am going to be foolish and make a prediction - that as Rails matures, it will start to gain some of the 'baggage' associated with larger frameworks like J2EE, because this 'baggage' will be found to be a useful part of creating a robust scalable system. For example, I would not be surprised to see, in a year or several, some sort of portable query language as an alternative to native SQL in Rails.

    I'm going to go out even further. I'll say by this time next year, we won't be talking about Rails anymore. I predict that the Spring-approach, be it Spring or clones will take us into 2007 and the current, minor but loud, dynamic craze will fall by the wayside into the realm of niche.
  48. Everything is RoR-a like?[ Go to top ]

    It is a misunderstanding that generated code from table schema must be ulgy. It is not true. Whether ugly or not depend on what the generated code try to do. If the generated code is kept simple and do one thing and do it well than it is not ugly. This is the lesson I learn from Rails and the book 'Better, Faster and Lighter Java'. Also most commentators has a syndrome called 'judge a book by its cover' which I learn from late Professor Richard Feymann's book 'Surely You are joking Mr. Feymann'. In the past, I was also a programmer who go against code generation because I find it is very difficult to understand or customize the generated code from IDE because those generated code is fitted for the IDE needs but not the programmer needs . These are the problems that we try to avoid in GenAndRun. By the way 'like RoR' means that we want to absorb the basic principles and some pratices of RoR which can help to improve the productivity of programmer. Just out of curiosity, it seems that most commentators think that Java must fail in the small or medium size application. Is it true? I don't think so as long as we can improve Java. I have take a look at Stripes by Tim Fennell. It looks quite good. Thanks Tim Fennell.

    Chris Tam
    GenAndRun contributor
  49. I am one of the contibutor to GAR and I would like to thanks the other developers comments. It is a fact that there are too few documentations on GAR. We will add more documentations in future. I really like Dion Almaer
    comment that "Rails != codegen" and it is also the reason that we assign version 0.1 to GAR rather than version 1.0. May Dion give us some ideas what features should we include into GAR? Thanks in advance. I also really like Javier Paniza comment that it is horror to generate business component from relational database but the problem is GAR does not generate the business component. GAR only generate model and dao class for retrieve and update data which contains no business logic. If anyone follow our Quick Getting Started Guide sample, you will have a Staff.java class without any method in the models directory. It should be the business component but it does not have any method because GAR does not know how to generate a business component. Steve Zara comment is one of our main current concern and problem. It seems that purely 'table driven development' does have some drawbacks and benefits. Also his 'full-featured two-way interactions' idea is a real insight to us because we have never though about it before. In summary, 1. GAR does not imply Rails = gencode. 2. GAR does not generate business component. Thanks a lot for the
    Steve Zara, Javier Paniza and Dion Almaer comments because their comments help to think and clarify some misunderstandings.
  50. Thanks a lot for the Steve Zara, Javier Paniza and Dion Almaer comments because their comments help to think and clarify some misunderstandings.

    As you have encouraged me :)

    Why the concentration on struts, ibatis and Hibernate? Not that there is anything wrong with these, but think of the flexibility you would give your users if you focussed on APIs that had multiple implementations, such as JSF and EJB 3.0. Then the user could plug-in whichever JSF implementation they wanted to use (Sun's RI, MyFaces etc.), and a range of EJB 3.0-compatible products - Hibernate, OpenAccess, Kodo, JPOX etc.

    My view is that support for JCP specifications (which would not prevent the use of popular products such as Hibernate) would add credibility to your project.
  51. all that negativity!!? I welcome every framework that at least tries to boost productivity. And offcourse the good old "Thou shall not develop table driven" mantra comes along. Application should follow the schema as close as possible (but not closer;). I hate object layers that obfuscate the schema.

    Relational data ugly? Try to fix a corrupt object database first and then come back and tell us about how easy and beautiful that was;-)))
  52. all that negativity!!? I welcome every framework that at least tries to boost productivity. And offcourse the good old "Thou shall not develop table driven" mantra comes along. Application should follow the schema as close as possible (but not closer;).

    I was not trying to imply that table driven development was entirely wrong, although it may have seemed like that. What I object to is frameworks that restrict you to only table-driven development. Sometimes your data model consists of more than the database. Sometimes the database is simply nothing more than a convenient way to persist information. For this reason frameworks should be flexible. After years of development of powerful products and APIs (Hibernate, JDO, EJB) that allow abstraction from the database, I am sure that many Java developers view pure table-driven development with caution.
  53. But ROR style is so Sexy[ Go to top ]

    all that negativity!!? I welcome every framework that at least tries to boost productivity. And offcourse the good old "Thou shall not develop table driven" mantra comes along. Application should follow the schema as close as possible (but not closer;).

    I was not trying to imply that table driven development was entirely wrong, although it may have seemed like that. What I object to is frameworks that restrict you to only table-driven development. Sometimes your data model consists of more than the database. Sometimes the database is simply nothing more than a convenient way to persist information. For this reason frameworks should be flexible. After years of development of powerful products and APIs (Hibernate, JDO, EJB) that allow abstraction from the database, I am sure that many Java developers view pure table-driven development with caution.

    Isn't it all about looking sexy :)

    I think it's great there's people working on tools for applications that only have 1 data model and 1 database. That fits a lot of cases. My bias is it's totally inappropriate for cases where the app is required to integrate with an outside vendor. Scrubbing the data as it comes in and going out isn't trivial and definitely doesn't fit the ROR style of development. Of course, outside vendors never change the model without telling others and apps never break because of unannounced changes. Nope, that never happens in real life.

    peter
  54. all that negativity!!? I welcome every framework that at least tries to boost productivity.
    I don't. Just ones that DO boost productivity. Of course they need to do it both now AND in the future.
    And offcourse the good old "Thou shall not develop table driven" mantra comes along.
    One man's mantra is another man's "I hate".
     Application should follow the schema as close as possible (but not closer;). I hate object layers that obfuscate the schema.
    Hmm. I don't care for objects that are basically structs for tables. :) Some times that is the thing to do, so I won't throw the baby out with the bath water. But intertwining the data and object models limits what can be done in both and between.
     Relational data ugly?
    No. The database. More specifically the model and what you have to do to get to it.
    Try to fix a corrupt object database first and then come back and tell us about how easy and beautiful that was;-)))
    Maybe true, but I don't think that a ODBMS is the posters suggestion. His suggestion is something you hate. :(
  55. And offcourse the good old "Thou shall not develop table driven" mantra comes along.
    One man's mantra is another man's "I hate".
    &nbsp;Application should follow the schema as close as possible (but not closer;). I hate object layers that obfuscate the schema.
    I shouldn't have used the word "hate", excuse me.
  56. I shouldn't have used the word "hate", excuse me.
    NP. You can hate inanimate objects.
  57. GenAndRun 0.2 - 3-min video demo released[ Go to top ]

    Hi

    GenAndRun 0.2 released with activeRecord feature. Anyone try?

    Pls don't miss the 3-min demo video in the demo section.

    Regards

    Oscar
    Xeniun
  58. Relational databases are so ugly[ Go to top ]

    Relational databases are so ugly
    Why? Impedance mismatch
    Is it ODMBS the solution? Not for me. I develop applications for AS/400 and against legate database, I cannot avoid relational database, who can it?

    But, if you want be pragmatic, when you obtain your object model directly and automatically from your tables, you have an ugly object model, and lost some of the benefits of OO. Specially if you work against legate database.

    As Java programmer, for me the ideal way of programming would be defining my Java classes, only my Java classes, and forgot at all of tables, foreing key, indexes, schema evolution, etc.
    Although I admit that for the moment forgot relational database is impossible.

    In other hand, using a DDL as specification language for a program generator has its limitations (how do you can extend it?). Maybe, using taglibs, UML or XML (XML is so beatiful for defining) is more flexible for this purpose.

    Javier Paniza
    www.openxava.org
  59. As John Stewart would say[ Go to top ]

    ROR has got to be the only thing more Over-hyped than the Daily Show. It's funny to see things go in cycles. Hopefully something else will take the crown as most over-hyped in 2006.

    peter
  60. You're giving me the RoR around ...[ Go to top ]

    Say what you want about RoR - but not "The Daily Show". It is the best fake news show ever. It had better watch its back, though, cause here comes "The Colbert Report" and "The Showbiz Show".


    As for Over-hype 2006? How about AJAX+Bleach or Web 2 & 1/2.
  61. You're giving me the RoR around ...[ Go to top ]

    btw, extra points to those who guess the "puns"/references.
  62. You're giving me the RoR around ...[ Go to top ]

    Say what you want about RoR - but not "The Daily Show". It is the best fake news show ever. It had better watch its back, though, cause here comes "The Colbert Report" and "The Showbiz Show".As for Over-hype 2006? How about AJAX+Bleach or Web 2 &amp; 1/2.

    AJAX is up there. they might be tied for most over-hyped. Silliness aside, these are tools. If a tool fits meets the requirements for the situation, then use it. If not, look else where. This whole debate about "you shall be more productive with product X" is non-sensical to me.

    peter