A fresh start after Hibernation

Discussions

News: A fresh start after Hibernation

  1. A fresh start after Hibernation (59 messages)

    There are some people left who still haven't played with Hibernate. Are you one of them? A few new resources have been released to help you get started. A new tutorial series named "The Road to Hibernate" walks you through some scenarios, and an excerpt from "Hibernate in Action" was published.

    Introducing The Road to Hibernate

    Get started with Hibernate

    Threaded Messages (59)

  2. It's all in your mind[ Go to top ]

    This constant talk about how programmers are in dire need of something to solve this mythical ORM problem is a self fulfilling prophecy. If you keep telling programmers that they arent skilled enough to learn and program in JDBC/SQL then they will start believing it.

    Sure if I am a building a petstore web site I may not need to know SQL but for any serious highend and performance sensative work you got to know your database and your SQL. Buy a SQL/JDBC book and go at it - it's not as hard as they make it seem. It is no harder than learning the ins and outs of Java, C++, or Unix/Windows OS programming.

    Nothing against products like Hibernate, they have their place, but they should not be made to sound like the end all be all.
  3. It's all in your mind[ Go to top ]

    This constant talk about how programmers are in dire need of something to solve this mythical ORM problem is a self fulfilling prophecy. If you keep telling programmers that they arent skilled enough to learn and program in JDBC/SQL then they will start believing it.Sure if I am a building a petstore web site I may not need to know SQL but for any serious highend and performance sensative work you got to know your database and your SQL. Buy a SQL/JDBC book and go at it - it's not as hard as they make it seem. It is no harder than learning the ins and outs of Java, C++, or Unix/Windows OS programming.Nothing against products like Hibernate, they have their place, but they should not be made to sound like the end all be all.

    I've yet to see a single post or article that stated using Hibernate prevents you from learning SQL. Could you point to one?
    Hibernate debugs in SQL! How exactly do you think someone would use any ORM and not learn SQL.

    Hibernate is supposed to make persisting to the database easier. This is not a function of avoiding handcoding SQL. We had, for example, a requirement that required us to port a product that used Oracle 9i to SQL Server. And it comes as no susprise to anyone who has had to write non-trivial applications on different databases that the SQL, despite the standard, is simply not the same on different database. Close, but non identical.

    Long story short. We used Hibernate in the Oracle version, so the port was barely worth using the term. Had we used native instead of sequence, in conjunction with a more generic naming convention for sequence, even the sequence to identity transition would have been even simpler. The primary issues were in places where jdbc was being used instead of Hibernate because the person didn't know Hibernate.

    We also found some minor differences in what data is available at what time during transactions when using Hibernate callbacks, but these were trivial and of course, triggers were different.

    Hibernate easily handled 85% of the port by changing dialects and we dealt with the rest.

    Somewhere along the line, despite using Hibernate, we had to know some SQL, but instead of devoting time to making sure our jdbc and sql properly supported both, we wrote the original application faster and ported easily.

    That effort and the time saved what not all in our minds. It was in our wallets.
  4. It's all in your mind[ Go to top ]

    When you use an ORM tool you still have to know your DB and SQL. But when you work with a rich domain model it helps you a lot not to write your own ORM tool (lazy loading, caching, mapping from tables to objects etc.)

    Reto
  5. It's all in your mind[ Go to top ]

    When you use an ORM tool you still have to know your DB and SQL. But when you work with a rich domain model it helps you a lot not to write your own ORM tool (lazy loading, caching, mapping from tables to objects etc.)Reto

    But who says we *need* a rich domain model, and lazy loading, and mapping tables to objects? This kind of stuff usually results in a crapload of classes with tons of public getters/setters which is totally un-object oriented and completely violates encapsulation.

    I've been working on large DoD systems, and we have never had a need for this ORM stuff. JDBC does everything we need.
  6. It's all in your mind[ Go to top ]

    I've been working on large DoD systems, and we have never had a need for this ORM stuff. JDBC does everything we need.

    Doesn't JDBC use tend to evolve into ORM in any large project?

    Consider what you have to do with JDBC:
    Construct a statement.
    Execute the statement.
    Extract items from a ResultSet (this can involve a lot of code for large tables)
    close the resultSet.

    If you are using a particular table in several places, it is messy to duplicate this code. A good place to put the code is in the method of a Class that represents the table. For example, a method might take a ResultSet as a parameter. This is also more supportable as information about the table is held in one place - the class representing it. With only a very little more coding you can make the class more useful by with methods to add, update and delete rows in the table. If this is done with many classes, it makes sense to make them all conform to a common interface, (say 'PersistenceCapable') so you have a general simple API that can be re-used in different applications. You now have an ORM! All that long-winded sequence of JDBC calls is replaced by a few method calls to a persistence-capable object, or if you are using a system with transparent persistence such as Hibernate or JDO, simply accessing objects can retrieve them, and they are automatically stored if they are modified.
  7. It's all in your mind[ Go to top ]

    Maybe it is just messy. We've seen two, I believe, two responses to ORMs: 1)I write my own 2)I use jdbc directly

    My issue, and perhaps the issues of others is that over time, raw jdbc tends to degenerate into a mess. Combating this alternately consumes a lot of time, time spent solving the problem. On the other hand, why do I want to learn another persons persistence framework that when it is unlikely that it is:
        As comprehensive as say Hibernate
        As well documented
        As well supported
        As well tested
        As portable(in the job sense)?
  8. It's all in your mind[ Go to top ]

    I'm working on a small webapp that has, oh, 20 SQL tables. The main domain object is a graphs of, perhaps, 8 of those tables.

    I've been doing the back end stuff (J2EE things) for years, but had little experience with the front end (Servlet, HTML, etc.).

    I looked at Spring, Tapestry, Struts, Hibernatte, iBatis, etc. all hoping that they would save me time for this project.

    What happened was I was basically stalled. Fighting configurations, deciphering the interelationships, etc.

    For this app, they were all a distraction. If I knew these technologies up front, that would be one thing, but since this was a small app, the time invested in trying to figure these out, and the concerns about what traps lay ahead, made me abandon them all, write a BaseControlServlet, a BaseDAO interface and implementation, and simply move forward.

    I found that you can not have a casual relationship with these frameworks, but really need to have a fairly intimate understanding of them to really leverage them. Each time I tried to use them I found road blocks that I simply did not want to invest time into clearing.

    So, I'm now just building the app and doing the work. I have a hard coded DAOFactory, talking to DAOs with hard coded SQL, surrounded with boiler plate Connection/Statement/ResultSets and try/catch/finally.

    Despite the wheels I've reinvented, it is easier to reinvent those few wheels than to take the time to learn a framework that is adding far far more than what I need.

    It's a hamfisted approach, not appropriate for a project with an 18 month development cycle. But for this quick little app it is straightforward.

    Finally, it is difficult to evaluate a framework as a novice in the domain without knowing how they help. They can list all sorts of features and bullet points about what they do, but unless you have fought those battles before, it is hard to appreciate the value they provide.

    So, I get to fight those battles now to better appreciate the work in the frameworks. But I'm also happy with my little app. It's clean, and straight forward. For the work I'm doing, whether I code in XML or Java is irrelevant. I'm at the stage when I have to connect to a different database than what I'm using, I'll make the database information a parameter, but for now it's all coded in the app. Java code is just as practical at this stage for parameters as a .properties file or XML.

    I love frameworks, I'm a big fan of frameworks. But the power of the frameworks is their complexity, and their adaptability comes from their generality. But this is also their downfall, this is what makes their start up time so high.

    Everytime I tried out one of these frameworks to get "my simple app" working, I ran into some detail that made me plunge deep into the inner workings, "my simple app" deviated from the charted plan and suddenly I'm deeper than I wanted to get at this point into these systems.

    Long term they have benefits, but right now I'm willing to be penny wise and pound foolish and chisel the few bits I need out of stone by hand.
  9. It's all in your mind[ Go to top ]

    I'm working on a small webapp that has, oh, 20 SQL tables. The main domain object is a graphs of, perhaps, 8 of those tables.I've been doing the back end stuff (J2EE things) for years, but had little experience with the front end (Servlet, HTML, etc.).I looked at Spring, Tapestry, Struts, Hibernatte, iBatis, etc. all hoping that they would save me time for this project.What happened was I was basically stalled. Fighting configurations, deciphering the interelationships, etc.For this app, they were all a distraction.

    Well, only two of those items are front-end. Regardless, I had the exact opposite experience. I had an started a new project based on Struts and added Spring and Hibernate. We only seven weeks from beginning to end. I decided this was a good opportunity to try out Spring and Hibernate to shave off dev time.

    Spring and the Spring/Hibernate combo exceeded my wishes. Retrofitting Spring into the app was easy and Spring made Hibernate even easier to manage. Total time to convert to Spring was about 2-3 days. In fact, the integration worked so well, that I setup a similar application for a guy who had only three weeks to get something out. He absolutely didn't have time to wrestle with anything but the business logic.

    He was productive in two days. When it was time to access the database, I spent maybe 40 minutes walking him through the setup on Monday and he was reading and writing to the database Wednesday.

    Now, bear in mind that I've been following Spring's development and did some reading sometime ago before finding a good point to use it. I had a good feel for what it could do and the benefits and was attracted by the fact that I didn't have to swallow all of it at once.

    Heck, it only took a day to port off of my homegrown Dynamic proxy security framework replacing my proxies with Spring AOP.

    I think the problem is that you tried all at once.
  10. It's all in your mind[ Go to top ]

    I think the problem is that you tried all at once.

    Yes, absolutely. Everything was a hurdle and I just threw my hands in the air and said "screw it" and started coding, and refactoring on the fly. Writing the code to load the primary domain object was quite nasty, confusing and didn't work the first time. But, all of the other objects were pretty much a cut-n-paste away, being quite flat. I may still adopt something like Hibernate, but at the time it was a maze of twisty passages, all alike, and was a black hole of, essentially, non-productive time. I wasn't in the mindset to absorb the entirety of the framework for "my simple app".

    "Progress? I've made lots of progress. I know a whole lot of things that won't work!"

    But, minimally, I know enough now that that my next project (coming soon) will leverage some of these frameworks.
  11. Apache Commons Dbutils[ Go to top ]

    I've found the Apache-Commons-DbUtils library particularly suited to this scale of development. It is a very lightweight library that manages for you connection clean-up, conversion from resultset to bean, statement batches and externalising sql, all of which I find create the niggles in any home-grown effort. Recommended.

    Kit
  12. It's all in your mind[ Go to top ]

    On the other hand, why do I want to learn another persons persistence framework that when it is unlikely that it is:    As comprehensive as say Hibernate    As well documented    As well supported    As well tested    As portable(in the job sense)?

    Hibernate is an excellent ORM system, but there are advantages in learning others. JDO 2.0 is a very comprehensive API, and there are a significant number of competing implementations, both free and commercial. This is a real advantage, as your code (and even compiled binaries) can be quickly transferred between different JDO implementations if you find one that has better performance and support. This is what standards like JDO are for: to encourage a competitive market in implementations that benefits the developer. With Hibernate, there will always be a lock-in factor, as migrating to another ORM is a lot more work. There are plenty of quality JDO suppliers, and JDO is certainly well tested and portable.
  13. It's all in your mind[ Go to top ]

    On the other hand, why do I want to learn another persons persistence framework that when it is unlikely that it is:    As comprehensive as say Hibernate    As well documented    As well supported    As well tested    As portable(in the job sense)?
    Hibernate is an excellent ORM system, but there are advantages in learning others. JDO 2.0 is a very comprehensive API, and there are a significant number of competing implementations, both free and commercial. This is a real advantage, as your code (and even compiled binaries) can be quickly transferred between different JDO implementations if you find one that has better performance and support. This is what standards like JDO are for: to encourage a competitive market in implementations that benefits the developer. With Hibernate, there will always be a lock-in factor, as migrating to another ORM is a lot more work. There are plenty of quality JDO suppliers, and JDO is certainly well tested and portable.

    The others I refer to are homegrown implemenations, not competing standards. I lump JDO, Hibernate, and Ibatis in the same basket. All of reasonsably transferable and well supported.
    "Another person's framework", not "another persistence framework."
  14. Are standards always better?[ Go to top ]

    Is it always better to use a tool that implements a standard? For instance, should your development process rely on Ant or the quality of your code rely on JUnit even though these are not standards?

    What about .Net? Is it only safe to use now that there's Mono?

    Is it better to use a standard like JDO? What if two implementations have subtle differences? What if one implementation provides a nifty extra feature that once used would be hard to give up?

    Is being standards-based only critical when considering commercial tools? Does "lock-in" have a different meaning when using a tool that is Open Source, freely available and has an active user community?
  15. Are standards always better?[ Go to top ]

    There are 2 types of standards: industry standards and defacto standards. Industry standards are arrived at by committee. Defacto standards are generally proprietary products that become standards because of their widespread use - like Microsoft's O/Ses. In my opinion, I would say that it's not the case the standards are always better, but it should be your first choice. If it isn't going to meet your needs, then look at other options. Using standards-based products will usually reduce risks when developing a new system.

    Now....two things - ORM tools and other products like them (such as middleware, appservers, etc.) are meant to keep you from having to do 'busy-work'. If the tool handles 80 or 90 percent of the task for you, that's one thing you don't have to be bothered with. Hopefully you can spend your time writing code for the business, not glue-type utilities or whatever. The second point is that ORM tools don't keep you from having a well-designed relational database. That's actually the whole point.

    -Scott
  16. Are standards always better?[ Go to top ]

    I'm wondering where Ant, JUnit and Hibernate fit in with these types of standards.

    They're not industry standards since they weren't arrived at by committee. On the other hand they're not really proprietary products since there are no restrictive licenses associated with them.

    On the other hand it does seem like these tools are standards in the industry. Maybe we could say these tools fall under a defacto/non-proprietary standard. If so, this standard should be viewed differently, with its own pros and cons. For instance, industry standards designed by committee look great, unless they look like they were designed by committee. Defacto/proprietary standards can become bloated and expensive as the vendor tries to add additional features to encourage customers to upgrade. Defacto/non-proprietary standards are often developed by small, focused groups which can lead to the development of very elegant solutions.

    So I'd say there are three "standards", each with its own pros and cons.
  17. Are standards always better?[ Go to top ]

    Defacto/proprietary standards can become bloated and expensive as the vendor tries to add additional features to encourage customers to upgrade. Defacto/non-proprietary standards are often developed by small, focused groups which can lead to the development of very elegant solutions. So I'd say there are three "standards", each with its own pros and cons.

    Regardless of terminology, I think the problem with any standard implemented by only one organization is that you're subject to that organization's timeline. If there is a feature missing, or the product isn't advancing fast enough, or it has a bug that is deemed unimportant by the authors but is important to you, you don't have any compatible solution to turn to. You're stuck.

    Obviously, an open source product at least has the advantage of you being able to modify the code. This is great for minor issues that are easily solved, but doesn't help much for bigger problems unless you're willing to take time away from developing your end product to work on whatever shortcoming you're hitting.

    Industry standards are implemented by multiple parties, and usually don't face this issue. And while I agree that sometimes "design by committee" can be a bad thing, it can often be a good thing as well. (It's also not as if open source projects can't suffer the same problems -- look at the lack of class/method/variable naming conventions in Python's standard library, for example).

    So in the end I agree with you -- each kind of standard has its own pros and cons. I just felt like no one was sticking up for the industry standards :)
  18. Are standards always better?[ Go to top ]

    .Now....two things - ORM tools and other products like them (such as middleware, appservers, etc.) are meant to keep you from having to do 'busy-work'. If the tool handles 80 or 90 percent of the task for you, that's one thing you don't have to be bothered with. Hopefully you can spend your time writing code for the business, not glue-type utilities or whatever. The second point is that ORM tools don't keep you from having a well-designed relational database. That's actually the whole point.-Scott

    Today I ran into an issue with an ORM DB

    I could not use a simple utility that deletes a grouping object.

    THis object contained 8 record objects from a particular batch job. Such objects can hold hundreds of thousands of record objects

    I ran the program, and it just hung.

    After working with the DBA, we realized it wasn't hitting the index. So we ran the query manually with a hint. The hint failed. If we let the query run, it might have finished in 3 or 4 hours.

    As it turns out the reason the hint was failing was due to the raw hexidecimal object ids used. The table needed to be reanalyzed? so that the DB would use the index (I apologize, I know that's not the right term). There is no good reason why it would ignore the hint, yet it did. Once the procedure was done, we were able to remove the objects in 2 seconds.

    Too often, we encounter issues like this, which I place squarely on a product that was built with ORM. Not only do I develop apps on the product, but I have to support our installation.

    Eat your own dog food? I wish I was able to do that, but I'm eating someone else's dog food, and it tastes like !*@
  19. Are standards always better?[ Go to top ]

    Is it always better to use a tool that implements a standard? For instance, should your development process rely on Ant or the quality of your code rely on JUnit even though these are not standards?What about .Net? Is it only safe to use now that there's Mono? Is it better to use a standard like JDO? What if two implementations have subtle differences? What if one implementation provides a nifty extra feature that once used would be hard to give up? Is being standards-based only critical when considering commercial tools? Does "lock-in" have a different meaning when using a tool that is Open Source, freely available and has an active user community?

    Lots of good questions. My view is that it is always by far better to use standards-compliant tools. There is a difference between tools used for development, such as Ant and JUnit, and systems which become part of your deployed code, such as Hibernate or JDO. Its far easier to move to new development and testing frameworks than to re-engineer the core of your code.

    As for JDO, you have a choice. You can use the extra features provided by a supplier, or you can keep your code very portable. These days, most of the extra features are likely to be part of the new JDO 2.0 standard anyway. With Hibernate you don't have a choice.

    I think your final question is very significant, as there is a modern Myth that just because a product is open source it can't be 'proprietary'. You can get just as much lock-in and vendor dependence with open source projects as with commercial locked code. User communities which are active now may be of little use when there is a problem left unfixed many years from now. Standards are good - they encourage competition and quality in products.
  20. Are standards always better?[ Go to top ]

    You make some good points.

    I'm just wondering if 'proprietary' fits here. According to Merriam-Webster:

    1 : one that possesses, owns, or holds exclusive right to something; specifically : PROPRIETOR 1
    2 : something that is used, produced, or marketed under exclusive legal right of the inventor or maker; specifically : a drug (as a patent medicine) that is protected by secrecy, patent, or copyright against free competition as to name, product, composition, or process of manufacture
    3 : a business secretly owned by and run as a cover for an intelligence organization
  21. It's all in your mind[ Go to top ]

    The question is, can you show where someone might have said that ORM is a replacement for SQL/JDBC knowledge? Could it be that the "constant talk" is something else and you might have misunderstood it? I'm pretty sure that no-one from our side of the ORM world has said something like this, as it would make no sense at all.
  22. Missing the point[ Go to top ]

    Sam, you're right about Hibernate and other ORM tools not being the end-all-be-all (this is true of every tool known to mankind), but I think you're missing the larger point.

    It's never been about telling programmers they're not *skilled* enough. It's about saving brain juice for higher-level problems like business requirements, workflow and a good UI. Are you smart enough to design your own operating system? Given enough time and cafeine, I guarantee you are, but why do it? Also, it IS hard (or at least hard work) to make custom JDBC solutions database-independant, capable of lazy loading, caching and object oriented, which are features that Hibernate, OJB, JDO and Toplink readily provide.
  23. It's all in your mind[ Go to top ]

    The benefits I've experienced with ORM is avoiding the tedious SQL/JDBC programming and the advantage of working with a domain model.

    It's not a holy grail for sure because there is additional learning curve. Still worth it IMO.
  24. Make sure it will not hinder the system[ Go to top ]

    My position against these sorts of tools has to do with my experience migrating data stuck in these formats.

    it becomes impossible to perform a migration quickly without impacting live customers when you have an immense amount of data within the structure. Millions of records of transaction history, a property table with 4 or 5 entries per transaction, millions of accounts with their own properties.

    It becomes unwieldly. Just have one thing go wrong and get out of sync and you have a nightmare when you try to figure out where the breakdown was in the workflow with a DBA who could care less about Java and objects.

    I think it is very important to make sure that the project you're working on is suited for this kind of product, which I think is sort of what the first poster was trying to get at.

    There's always tradeoffs, and from my experience using a product built with a professional ORM tool, I would have preferred to stick with a straight relational structure that we migrated from. The support was much easier, and the time and cost of maintaining the platform was much less than it is currently
  25. My position against these sorts of tools has to do with my experience migrating data stuck in these formats.it becomes impossible to perform a migration quickly without impacting live customers when you have an immense amount of data within the structure. Millions of records of transaction history, a property table with 4 or 5 entries per transaction, millions of accounts with their own properties.It becomes unwieldly.

    Yikes! I think you have a point Mike, ORM tools are NOT designed to handle this type of problem set. In fact, I think I'd use the native SQL of which ever database(s) were involved to carry out this type of transaction.

    I can't imagine how slow or memory-intensive doing a migration that large would be.
  26. My position against these sorts of tools has to do with my experience migrating data stuck in these formats.it becomes impossible to perform a migration quickly without impacting live customers when you have an immense amount of data within the structure. Millions of records of transaction history, a property table with 4 or 5 entries per transaction, millions of accounts with their own properties.It becomes unwieldly.
    Yikes! I think you have a point Mike, ORM tools are NOT designed to handle this type of problem set. In fact, I think I'd use the native SQL of which ever database(s) were involved to carry out this type of transaction.I can't imagine how slow or memory-intensive doing a migration that large would be.

    Some ORM tools are definitely designed to handle this kind of problem. There are high-end JDO systems around that have carefully designed memory and cache control features to allow their use on very large data sets.

    This is one thing that has always bugged me about Hibernate - the developers seem to encourage use of native SQL for certain types of database activity (large batch jobs, for example) - whereas the attitude of the JDO vendors I have dealt with is that a good ORM system should be able to cope with any database activity. Drop through to native SQL and you are almost certain to lose portability.
  27. In practice, no one cares about portability, because enterprise applications (we are not talking about your average 50 entities webapp) are not ported anywhere, they run for years, once they run. It's nice to be able to port, but running your batch job in Java memory instead of a stored procedure is just insane. You are looking for a solution for a non-issue.
  28. In practice, no one cares about portability, because enterprise applications (we are not talking about your average 50 entities webapp) are not ported anywhere, they run for years, once they run. It's nice to be able to port, but running your batch job in Java memory instead of a stored procedure is just insane. You are looking for a solution for a non-issue.

    I could not disagree more strongly. Portability is a vital concern for many enterprise developers (why else would Java be so popular?). Stored procedures and non-portable hand-coded SQL can potentially be the long term death of an enterprise system, as any attempt to migrate to a different database vendor can be a huge and expensive procedure. I am dealing with several examples of this kind of migration, and its definitely not a non-issue!
  29. Portability/Migration[ Go to top ]

    <Steve Zara>
    Stored procedures and non-portable hand-coded SQL can potentially be the long term death of an enterprise system, as any attempt to migrate to a different database vendor can be a huge and expensive procedure. I am dealing with several examples of this kind of migration, and its definitely not a non-issue!
    </Steve Zara>

    Migration is painful for sure. But in large scale applications usage of Stored Procedures and proprietary SQL is unavoidable. That is the reason we have created database migration tools to migrate Stored Procedures, SQLs etc. from/to Oracle, SQL Server, DB2, Sybase etc.

    Take a look at SwisSQL from AdventNet.

    We even have SQL APIs which can be embedded in Java/C# applications which automatically convert proprietry SQL queries to different database dialects at runtime.

    We do get quite a few customers for SwisSQL. That means people still use proprietary SQL queries in their code (because it is unavoidable) and many also use Stored Procedured for performance and various other reasons.

    Sekar
  30. Portability/Migration[ Go to top ]

    <Steve Zara>
    Stored procedures and non-portable hand-coded SQL can potentially be the long term death of an enterprise system, as any attempt to migrate to a different database vendor can be a huge and expensive procedure. I am dealing with several examples of this kind of migration, and its definitely not a non-issue!
    </Steve Zara>

    Migration is painful for sure. But in large scale applications usage of Stored Procedures and proprietary SQL is unavoidable. That is the reason we have created database migration tools to migrate Stored Procedures, SQLs etc. from/to Oracle, SQL Server, DB2, Sybase etc.

    Take a look at SwisSQL from AdventNet.

    We even have SQL APIs which can be embedded in Java/C# applications which automatically convert proprietry SQL queries to different database dialects at runtime.

    We do get quite a few customers for SwisSQL. That means people still use proprietary SQL queries in their code (because it is unavoidable) and many also use Stored Procedured for performance and various other reasons.

    Sekar
  31. Portability/Migration[ Go to top ]

    But in large scale applications usage of Stored Procedures and proprietary SQL is unavoidable.

    As good ORM systems such as Hibernate and JDO 2.0 provide query languages with the same functionality as SQL, this is false.

    There may be cases where the use of hand-coded proprietary SQL and stored procedures (as against that generated by the ORM) is preferable, or more convenient, but its certainly not unavoidable.
  32. In practice, no one cares about portability, because enterprise applications (we are not talking about your average 50 entities webapp) are not ported anywhere, they run for years, once they run. It's nice to be able to port, but running your batch job in Java memory instead of a stored procedure is just insane. You are looking for a solution for a non-issue.

    Again, I disagree. Because I've been there and done it.

    And I'm not running Java jobs to do a migration...talk about SLOW! We're talking about running SQL jobs to handle the migration. We're talking about additional time requirements to create procs that handle it. We're talking about hours of time with DBAs trying to explain to them how the database structure looks because it doesn't make sence. We're talking about hours of writing support applications that don't need to exist since the support staff knows SQL, but struggles learning how Object IDs aren't a readable number.

    It reminds me of business 101. You always have certain problems in marketing a product. You have to manufacutre, you have to distribute, and you have to sell.

    Now you can create a warehouse and do everything at one building...but it doesn't remove any of the issues.

    So by using an ORM tool, we make it simpler for developers. However we pass the complexity problem to the DBAs, support staff, etc.

    The point is, when going in to architect a solution you need to understand your audience and determine where it is best to use ORM, and where it is best to let DBAs do the data mapping.

    It bugs me to no end to see people talk about ORM being the be-all-end-all. It's not. It's a tool. And just like using a sledgehammer to put a nail in the wall for a picture....not all tools are the "right" one for the job.

    Just because it makes your life easier does not mean it's the best for your company.
  33. So by using an ORM tool, we make it simpler for developers. However we pass the complexity problem to the DBAs, support staff, etc.The point is, when going in to architect a solution you need to understand your audience and determine where it is best to use ORM, and where it is best to let DBAs do the data mapping.
    I think it is better to design DB and ER model first too, if this model is good then ORM can not break it, do not let programmers and webmasters to execute any DDL if database is important for you.
  34. In practice, no one cares about portability, because enterprise applications (we are not talking about your average 50 entities webapp) are not ported anywhere, they run for years, once they run.

    Now this may be true for your practice, but not necessarily for everbody else's.
    It's nice to be able to port, but running your batch job in Java memory instead of a stored procedure is just insane.

    This depends on many factors. What seems insane for your, may be perfectly reasonable for other people.
    You are looking for a solution for a non-issue.
    Same old comment here...

    I think it would very beneficial to the discussion if people stopped implying that their problems are a) representative of everybody else' problems or b) the only relevant ones.

    Kind regards,
    Oliver
  35. My position against these sorts of tools has to do with my experience migrating data stuck in these formats.it becomes impossible to perform a migration quickly without impacting live customers when you have an immense amount of data within the structure. Millions of records of transaction history, a property table with 4 or 5 entries per transaction, millions of accounts with their own properties.It becomes unwieldly.
    Yikes! I think you have a point Mike, ORM tools are NOT designed to handle this type of problem set. In fact, I think I'd use the native SQL of which ever database(s) were involved to carry out this type of transaction.I can't imagine how slow or memory-intensive doing a migration that large would be.

    Some ORM tools are definitely designed to handle this kind of problem. There are high-end JDO systems around that have carefully designed memory and cache control features to allow their use on very large data sets.

    This is one thing that has always bugged me about Hibernate - the developers seem to encourage use of native SQL for certain types of database activity (large batch jobs, for example) - whereas the attitude of the JDO vendors I have dealt with is that a good ORM system should be able to cope with any database activity. Drop through to native SQL and you are almost certain to lose portability.
  36. 2 Mike Cornell
    My position against these sorts of tools has to do with my experience migrating data stuck in these formats.

    What's migration of data has to do with day to day use ?
    What it has to do with regular user applications ?
    It's like saying "My position against cars has to do with my experience migrating car from London to New Yourk."
  37. 2 Mike Cornell
    My position against these sorts of tools has to do with my experience migrating data stuck in these formats.
    What's migration of data has to do with day to day use ?What it has to do with regular user applications ?It's like saying "My position against cars has to do with my experience migrating car from London to New Yourk."

    Not really.

    It has everything to do with day to day use.

    Day to day, I cannot simply go in and run simple SQL to find issues as easily as I could in a relational model.

    There is not a week that goes by that I do not get a call from a lesser experienced tech who cannot figure out an issue from reading the database. They want to run a query, but cannot understand how to do it as they did in the older system.

    The support costs day-to-day have been much higher, let alone the migration costs that make it much more difficult to move data in real time.

    The easier the system is to support, the more likely it is to stay around.

    The original system was in play for 8 years. The new system has been in play for 2.5 and is already being looked at being replaced with a system that is a hybrid between the two, where more support and transaction intestive functions are replaced with relational tables.
  38. Day to day, I cannot simply go in and run simple SQL to find issues as easily as I could in a relational model.
    ...
    They want to run a query, but cannot understand how to do it as they did in the older system.
    :)) Ever heard about views ?

    What's the complexity of system has to do with user fouling around with his favorite sql reporting tool ?
    The system is as complex as it required by its domain model. I hope you do not model your system based on experience of your Crystal Reports users ? :))

    Man, you really should learn using right tool for the right job. ORM is not for you.
  39. Day to day, I cannot simply go in and run simple SQL to find issues as easily as I could in a relational model.
    ...
    They want to run a query, but cannot understand how to do it as they did in the older system.
    :)) Ever heard about views ?

    What's the complexity of system has to do with user fouling around with his favorite sql reporting tool ?
    The system is as complex as it required by its domain model. I hope you do not model your system based on experience of your Crystal Reports users ? :))

    Man, you really should learn using right tool for the right job. ORM is not for you.
  40. :)) Ever heard about views?
    Hmm, should everyone working with ORM learn SQL, and everyone working with HTML learn HTTP spec, and everyone creating VB apps learn Win32? Naaaah, this is too much to ask ;-)
  41. :)) Ever heard about views?
    Hmm, should everyone working with ORM learn SQL, and everyone working with HTML learn HTTP spec, and everyone creating VB apps learn Win32? Naaaah, this is too much to ask ;-)

    Thats typical question and answer is:

    1. NO need SQL to 5 tables
    2. NO need HTTP for 5 HTML pages
    3. NO need Win32 for VB unless you try use f.e MultimediaAPI

    And

    1. YES, you need SQL knowlodge for 200+ tables
    2. YES, you need know HTTP, if want to send multipart request and recieve multipart response
    2. YES, you need Win32 if you run out VB (COM) functions
  42. Fnd more important,

    4. YES, if you want even get more money then NOW
  43. migration question[ Go to top ]

    I am interested, how refactoring of object model works with ORM tools? For example I decide to move some property to parent class or change its type .. Or I add brand new property.

    What will happen when I start my application with new classes (ORM config) and old schema? Or is there some tool, which accepts old classes and old config in one dir and new classes and new classes in second dir and performs some magic to fix DB schema and updates existing records?

    With JDBC I've got precise knwoledge of change on DB side and on Java side, so I prepare conversion script. If I was ORM programmer, what am I supposed to do, when I feel need of object mode change?
  44. migration question[ Go to top ]

    If I was ORM programmer, what am I supposed to do, when I feel need of object mode change?

    Good ORM systems provide tools for schema migration of live systems.
  45. migration question[ Go to top ]

    Again, absolute non-issue (did you read this in some marketing slides?). Your corporate DBA will cut of your fingers if you try to run automatic schema evolution tools on his production database.
  46. migration question[ Go to top ]

    Again, absolute non-issue (did you read this in some marketing slides?). Your corporate DBA will cut of your fingers if you try to run automatic schema evolution tools on his production database.

    I AM the corporate DBA! Its not marketing stuff - I use these tools in real situations. It doesn't have to be automatic migration. What saves the time and trouble is when you change the object model and then the SQL to perform the migration is automatically generated. This SQL can, of course, be previewed and edited before being run.
  47. It's all in your mind[ Go to top ]

    This constant talk about how programmers are in dire need of something to solve this mythical ORM problem is a self fulfilling prophecy. If you keep telling programmers that they arent skilled enough to learn and program in JDBC/SQL then they will start believing it.

    In all enterprise projects I participated sooner or later developers ended up implementing their own starategies to store/rertieve objects from database. It's simply impossible (at least unmaintanable from my experience) having 200+ (middle sized project) business entities and live without ORM of some kind (I'm talking about java). Well must say that all this home grown frameworks had a lot of issues and tradeofs. They grew up from JDBC code and lack of some kinds of mappings (only simple relations, no lazy loading) etc. etc. I strongly agree with Gavin King that claims that implementing another yet persistence framework isn't good idea in the most cases.

    In my humble opinion and experience - writing middle-sized and bigger applications using JDBC is a complete pain. It could be possibly faster a bit, but it is at a cost - cost of maintenance.
    Sure if I am a building a petstore web site I may not need to know SQL but for any serious highend and performance sensative work you got to know your database and your SQL.

    Could not disagree more. Using ORM and having native SQL are not mutually exclusive things. All decent ORM solutions have quite good support for native SQL. You can always use native SQL just get JDBC connection and perform some native tasks (bulk operations are good example in the case of HB). But I'm not convinced why handcoded SQL must be always (or even in most cases) better?
    Buy a SQL/JDBC book and go at it - it's not as hard as they make it seem. It is no harder than learning the
    ins and outs of Java, C++, or Unix/Windows OS programming.

    It *is* hard. It is hard in terms of testability and maintabilty. It could be possible a bit faster than ORM (but only if You implement pools, second level cache, lazy loading etc.) - but as I said it's at a cost.
    Nothing against products like Hibernate, they have their place, but they should not be made to sound like the end all be all.

    Who said that that they are "end-all-be-all"?

    Artur
  48. Could not live without orm[ Go to top ]

    In my company (specialized in financial and insurance software), we work with huge doamin models (more than 1000 persistent objects), and we have developed a few years ago (2 years before Hibernate actually) a full ORM implementation. It's not perfect (I miss my Hibernate), it's an order of magnitude less performant than raw sql / jdbc (we still need to work on joins), but I would not want to go back to good old sql: another solution we sell is based on sql, I've seen queries of 9 pages !!!

    I agree that for some projets, ORM is overkill, but god, you feel happy with your OQL (object query language, any of it, may it be ejbql or hsql) when you have to make an 8 table deep join to get a third party and its accounts. Also, you have true domain objects, instead of rowsets and thing managers (boo) that perform logic on map like data.

    However, I think that you still have to understand SQL and the relational model to use Hibernate. Unfortunately (imho), you still feel sql and its limitations behind every orm tool.
  49. It's all in your mind[ Go to top ]

    ORM is not about knowing or not knowing SQL. It is about object-based persistance and reusability of your data-acess layer(iBatis is a good example wher you use SQL for SQLMaps). Do not tell me that hardcoding the same SQL and JDBC code for slightly different situtation is a better way. And than try porting your PL/SQL from one DB vendor to another, which is another goal of ORM - DB Vendor abstraction.

    Hibernate or any other tool, but ORM aproach definitely has its advantages and some frameworks implement it very nicely.
     If you keep telling programmers that they arent skilled enough to learn and program in JDBC/SQL then they will start believing it.

    There is nothing magical or complicated about programming in SQL/JDBC paradigm - it is tedious and time consuming, and the real skill is how to work around it's limitations and code verbosity and make good time on the project delivering a stable and scallable product.

    I do not think your client prefers you to spend time on writing JDBC code, rather than spend time on writing business specific code.

    Regards,

    Artem D. Yegorov
    http://www.activexml.org
  50. It's all in your mind[ Go to top ]

    Nothing against products like Hibernate, they have their place, but they should not be made to sound like the end all be all.
    I'm not sure that Gavin has that in his mind when he talks about Hibernate. You should read his (and Chris Bauer) book. In that book, they explain what Hibernate is and is not good for.
    Even if you don't think Hibernate is what you need, you should at least give it a chance, just to improve your understanding and know what people are talking about if you hear about it. And they don't say it's the end all be all. Read it, build your own opinion and then come back and share your knowledge and your feelings with us. I guarantee you won't waste your time doing so.

    Regards,
    Jean-Pol.
  51. A year ago when I was just starting a new iteration of a product I am working on, I was looking to replace a proprietary, specialized database layer with a generic OR mapping layer. Before, I would just write one and it would work great, as I have already written a couple of generic OR layers, but I thought OK, this time around I am going to get a bunch of products and integrate them. I've succeded in that but during the project I've reaffirmed the main principle that I used and will use going ahead which is simplisity. The hibernate is by no means a simple framework whatever the angle you look at it from. It has plenty of dependencies some of which may clash with versions of dependencies of other products you integrate. It introduces a new SQL like query language, do I need one more? I am sure that there are arguments that prove that yes I do, but I'd rather not have it. It 'flushes' changes to the database when transaction commits. I prefer my program to fail fast, not when hibernate decides to flush(you can flush programmatically). Late flushing is a bad practice! Anyhow, my dissatisfaction with Hibernate grew pretty high towards the end of the project.

    I am currently working on the next release and I did start fresh: with my own framework, back to simplicity. The vendors of OR tools say that the strongest competition comes from development teams that build their own frameworks, and they are right! Perhaps if they choose to keep it simple they would be more successful.

    I wrote my framework as an open source project, you can check it out at http://jdbcpersistence.dev.java.net
  52. I need one more? I am sure that there are arguments that prove that yes I do, but I'd rather not have it. It 'flushes' changes to the database when transaction commits. I prefer my program to fail fast, not when hibernate decides to flush(you can flush programmatically). Late flushing is a bad practice! Anyhow, my dissatisfaction with Hibernate grew pretty high towards the end of the project.I am currently working on the next release and I did start fresh: with my own framework, back to simplicity. The vendors of OR tools say that the strongest competition comes from development teams that build their own frameworks, and they are right! Perhaps if they choose to keep it simple they would be more successful.I wrote my framework as an open source project, you can check it out at http://jdbcpersistence.dev.java.net



    u can see the SDO specification for the Alternative of Heberante , SDO is much more than the any OR mapping tool.

    http://dev2dev.bea.com/technologies/commonj/sdo/index.jsp
  53. These words are made of gold:
    back to simplicity
    I also contributed to simplicity a bit. Please take a look at SQLC and an Article about it.
  54. Hibernate and xDoclets[ Go to top ]

    Everyone teaches you the very fresh start of Hibernate, but no-one talks about xdoclects.

    I myself can't stand reading XML, as it is not natural and generally annoying.
    Instead i like to read Java code, and used to reading JavaDocs, so xdoclets is the preferred way of configurating things.

    So please, anyone that writes new tutorials, use xdoclets and not the regular mapping.
    And anyone that knows a good tutorial (other than the ones on the official xdoclets site), please let me know.
    Jus.
  55. Hibernate + KDoclet[ Go to top ]

    So please, anyone that writes new tutorials, use xdoclets and not the regular mapping.And anyone that knows a good tutorial (other than the ones on the official xdoclets site), please let me know.

    XDoclet in Action
    http://www.manning.com/walls
  56. Great Thread[ Go to top ]

    This thread epitomizes an old paper I wrote a few years ago. I blew the dust off, updated it a bit, and put it on my blog. The bottom line is that we tend to confuse "Technical Impedance Mismatch" with the business and political impedance mismatch that are a reality in every development shop...

     - Don
  57. Great blog entry[ Go to top ]

    This thread epitomizes an old paper I wrote a few years ago. I blew the dust off, updated it a bit, and put it on my blog. The bottom line is that we tend to confuse "Technical Impedance Mismatch" with the business and political impedance mismatch that are a reality in every development shop...&nbsp;- Don

    Just read it - very insightful, thanks Don.
  58. Great blog entry[ Go to top ]

    Oh, just realized that you're the Don Smith that presented ORM & TopLink at a certain large midwestern financial company last year. Good to see (er, read) you again!
  59. Great Thread[ Go to top ]

    Good article!
    Spouting off an opinion on how to architect an application where Java-hits-a-database without any in depth knowledge of the application and the culture of the organization trying to build it only proves your (lack of) experiences in the problem space -- nothing more.

    If more people followed this advice, things would go so much more smoothly ..... but TSS threads would be only half the size!

    Kit
  60. For those, who doesn't read yet[ Go to top ]

    For those, who doesn't read yet: begin since 'So What's the Problem?'

    --
    Mike