Discussions

News: Using Hibernate3 as a JDBC framework

  1. Using Hibernate3 as a JDBC framework (114 messages)

    The Spring guys often talk about when ORM can be overkill, and when simpler frameworks like iBATIS can come into play. Gavin King discusses how Hibernate itself can be used as a JDBC framework.

    Read Using Hibernate3 as a JDBC framework

    Threaded Messages (114)

  2. Not really for "simple" apps[ Go to top ]

    Keep in mind that this is not really a concurence to iBatis. This is not "dynamic sql maps" like iBatis employs. This is mostly a possibility to manually specify SQL used for loading objects, collections, etc.

    I really would not recommend doing a "complete SQL based Hibernate" application. I rather find this useful for tuning special cases or mapping some exotic legacy table structures which can not be achieved by "standard" Hibernate mappings.

    This is IMHO not for "simple" apps. In that case just doing a normal mapping and let Hibernate handle everything is still much easier.
  3. Not really for "simple" apps[ Go to top ]

    I really would not recommend doing a "complete SQL based Hibernate" application.
    It must be a good way too. I found "pseudo view" is a very usefull feature too. If it will be possible to update/delete without loading data to memory and without session level cache then it will be complete data access tool, it conflicts with "dirty detection" and "cascade" features, but I have reasons to avoid some features.
  4. I'm very glad this is coming to Hibernate, although it looks like some features in iBatis (such as named params used in the sql maps) are not available in Hibernate.

    Spring makes it trivial to mix and match Hibernate and iBatis code, and I've taken advantage of this in the past by doing most of the db operations in an app with Hibernate, due to it's pretty powerful o/r mapping capabilities, but using iBatis for some special cases. One is for queries where a handwritten complex SQL query will be handled by an iBatis SQL Map query, and the results returned as a custom JavaBean used just for that query (i.e. it's not a general domain object). Alternately, for some queries I just return the result as a HashMap directly. The latter capability is not mentioned in this article, but I believe it's also available in Hibernate 3. Aside from typical apps, where I've found iBatis very useful is for ETL (Extraction, Transformation, and Loading) type uses, where it is trivial to use Java in a script-like fashion, or called from Groovy, using iBatis SQL maps to get data in and out as HashMaps or real objects, manipulate it in some way, and pump it back out. This is useful for migration scripts to convert between schema versions, for example. I'm not sure Hibernate would have much of an advantage over iBatis for this last case, but on the other hand, if you are already using Hibernate elsewhere, you would probably use it for this application as well.

    Regards,
    Colin
  5. Gavin:
    The first thing to notice is the handwritten INSERT, UPDATE and DELETE statements. The ? order of the parameters matches to the order in which properties are listed above (we'll have to eventually support named parameters, I suppose).
    I did not quite get it. id is defined before name, but in "INSERT INTO PERSON (NAME, ID) VALUES ( UPPER(?), ? )" name comes before id. How does it know which is which? This works in pure JDBC where I supply the parameters directly, how exactly this works in this example?
  6. order of parameters[ Go to top ]

    I did not quite get it. id is defined before name, but in "INSERT INTO PERSON (NAME, ID) VALUES ( UPPER(?), ? )" name comes before id.
    Oh, my bad; I should have said <id> is special. It always comes last, though it is defined first. Which means that the order of things in INSERT and UPDATE statement are the same. There is actually a really, really interesting application for this, which I won't mention now. I'll leave it for a future blog .. con't give *everything* away too fast ;-)
  7. order of parameters[ Go to top ]

    I did not quite get it. id is defined before name, but in "INSERT INTO PERSON (NAME, ID) VALUES ( UPPER(?), ? )" name comes before id.
    Oh, my bad; I should have said <id> is special. It always comes last, though it is defined first. Which means that the order of things in INSERT and UPDATE statement are the same.
    I see. What about DELETE? Am I supposed to delete using PK only?
  8. bulk operations[ Go to top ]

    I see. What about DELETE? Am I supposed to delete using PK only?
    Hibernate doesn't yet have a bulk update/delete API. It is officially slated for Hibernate 3.1. However, it is a trivial thing to implement once we switch in the brand-new-Joshua-Davis-written query translator.

    At that point, native-SQL bulk update/delete will also be trivial to add.

    IN the meantime, direct JDBC is a perfectly reasonable way to do a bulk delete.
  9. bulk operations[ Go to top ]

    ...meantime, direct JDBC is a perfectly reasonable way to do a bulk delete.
    IMHO, JDBC is perfect for everything, with a bit of code gen for the java. But, as a solution, JDBC doesn't create the lovely problems of the larger frameworks, which makes things less interesting.

    Jonathan
    Emeraldjb - a green DAO code generator
  10. bulk operations[ Go to top ]

    ...meantime, direct JDBC is a perfectly reasonable way to do a bulk delete.
    IMHO, JDBC is perfect for everything, with a bit of code gen for the java. But, as a solution, JDBC doesn't create the lovely problems of the larger frameworks, which makes things less interesting.
    Direct JDBC has its own "problems". :)
  11. bulk operations[ Go to top ]

    Direct JDBC has its own "problems". :)
    Only because it's been locked in the dark for years and is now paranoid. You try beinging it into the light and see the framework dudes get their clubs out to beat it to death (again).

    Long live JDBC. Ulp.

    Jonathan
    Emeraljdb- green and sparkly.
  12. I like this one[ Go to top ]

    Ted Neward:
    "Object-relational technologies are the Vietnam of the Computer Science industry." Vendors who go down this road, usually find about the same results emerge as the US did in Vietnam.
    http://neward.net/ted/weblog/index.jsp?date=20040721#1090456235411
  13. I like this one[ Go to top ]

    Ted Neward's very correct observations concern project teams building their own ORM solutions. This is of course insane, and we would never, ever advocate this.

    That is why people use what we already implemented for them.
  14. Same as custom JDBC code[ Go to top ]

    Agreed, and it's the same with custom JDBC code. Starts of simple enough, but each and every time I've seen these JDBC DAOs grow into medium and large-sized enterprise apps, it gets to be a bear to maintain. One developer starts loading stored procedures, another (unaware of the functions already written, or needing a few extra fields) writes more procs (or worse, modifies the existing ones and breaks other client code). Then the company switches DB vendor standards and the business client throws regulatory-based requirements at the team, already working with more DTOs (or partially filled ones) than they're happy with. But no time to tally, deadlines loom, so more code is layered on top (or worse, those stored procs get changed again). Of couse, the business layer becomes more and more complex as a result, mixing business logic with an inconsistent array of DTOs and DAO calls, each seemably tailored to the a specific function. Then reporting requirements are laid on, needing joins and subqueries, and someone thinks it's a great idea to expose the business tier as web services, so you have to guess with methods and DTOs clients will want in 6-36 months. Then the clients start complaining about performance, so you go back and try to refactor n+1 reads problems all over the place (the developers THOUGHT that using existing DAO methods was a good idea), fiddle with caching via HashMaps and try to track down all of the client code which can be changed to take advantage of it. You leave lazy instantiaion by the wayside - too hard to implement transparently at this point, and start to contemplate if those silly ORM people might have had a point after all...
  15. Same as custom JDBC code[ Go to top ]

    Agreed, and it's the same with custom JDBC code. Starts of simple enough, but each and every time I've .......
    LOL

    Who has worked on a legacy Hibernate project yet? What was it replaced with. If none yet, then just wait 2 years and see them howl in the same way.

    Jonathan
    Emeraldjb- Not a space ship. But Green.
  16. IMO the reason that people disagree about O/R is that they are talking of different kind of projects. Everyone that is not new to the contract consulting know the horrible conditions that amounts to something like this (if it were construction building): "Please add a swimming pool at the top of Empire State Building and add 10 floors at the bottom to Monday".

    Under these conditions I admit that O/R can be a time saver. But sometimes you have the opportunity to do a quality work, like when it is a product to be resold many times or a very important system for airports etc..

    I hope nobody thinks that the SAP software engineers use something like Hibernate when they are building their systems!

    Regards
    Rolf Tollerud
  17. O/R==only for quick and dirty jobs[ Go to top ]

    So writing it all on your own is better than a tried and trusted framework? Funny how many projects end up with a home grown O/R api when the start to refactor out the duplicated logic.
    I hope nobody thinks that the SAP software engineer use something like Hibernate when they are building their systems!
    It is quite evident that they don't. Sadly.
  18. Isn't SAP on the JDO eg?[ Go to top ]

    And didn't SAP build their own JDO implementation? Or does my memory fail me?
  19. O/R==only for quick and dirty jobs[ Go to top ]

    Funny how many projects end up with a home grown O/R api when the start to refactor out the duplicated logic.
    Yup, this is exactly what will happen. I faced this problem quite a few years back when O/R tools were few and far between...and certainly not free. I ended up with my own O/R stuff, which was very limited due to time constraints but absolutely necessary in keeping 10+ developers somewhat productive without totally messing things up. If there had not been anything to raise the abstraction level and making things simpler, it could have been a real ordeal!
  20. Same as custom JDBC code[ Go to top ]

    I doubt it - Hibernate support will have to degrade pretty badly to match that required long-term by custom (or even generated) JDBC DAOs in my experience.

    After one year with Hibernate on a very active project, I can safely say that it's been a happy constant throughout the term. Now, I'm not saying that it's improved anyone's love life, reduced cholesterol levels or even made grocery shopping more pleasant, but it's been measurably easier to develop and maintain. We're making full use of caching and lazy instantiation with great results - something we wouldn't have time to write and test on our own.

    Recently a requirement for Informix connectivity was added, and it was a breeze to set up. Likewise, PostgreSQL and MS SQL have been bantered about (don't ask - it's a corporate thing), but it's left us with few worries, even through the syntax is fairly different in spots. How does Emeraldjb do with these (and other) DBs? And lazy instantiation? And multiple caching strategies? Can you change from one DB's dialect to another with a single line of code? What about query by example and incremental Criteria construction?

    Scott
  21. Emeraldjb - Green and sparkly[ Go to top ]

    I doubt it - Hibernate support will have to degrade pretty badly to match that required long-term by custom (or even generated) JDBC DAOs in my experience.After one year with Hibernate on a very active project, I can safely say that it's been a happy constant throughout the term.
    Good. It means it does what it says on the box. I'm working in a team with a 13 year old code base. Hibernate be around in 13 years? How about Oracle? I know Oracle will be. And Hibernate skills by then will be v v expensive. Not only that, but which version? Pre EJB3.0, or post EJB 5.0.
    How does Emeraldjb do with these (and other) DBs? And lazy instantiation? And multiple caching strategies? Can you change from one DB's dialect to another with a single line of code? What about query by example and incremental Criteria construction?Scott
    Nice flame. Emeraldjb is not about software theory and polymorphic relational database designs to support in memory object models. Emerald is about getting the database right, and then updating it, and mining it in a very simple way. No runtime components, no runtime xml, and no open source libs polluting your code base. Again - think long term, software does not exist only in the now.

    Imagine next year a great DB reporting tool comes out, one which publishes to web, integrates with excel and olap cubes. The full reporting mantra. And your users want to use it. How important is your object model then? At that time the important thing is a well designed database, which will support many technologies.

    But horses for courses - use hibernate if you find it fun, and if, as you imply, java objects over multi databases is important enough to your situation that you want a huge runtime component.

    Jonathan
    Emeraldjb - Swirling green which is NOT hibernate.
  22. I like this one[ Go to top ]

    Ted Neward's very correct observations concern project teams building their own ORM solutions.
    Ahem. To quote Ted:
    Both major software vendors and project teams (building their own O-R layer) fall into the same trap.
    I guess Hibernate project/JBoss Inc. is a major software vendor. Good luck fighting the insurgents...
  23. I like this one[ Go to top ]

    That comparison with the viet war is simply stupid. United States have lost the war because they were not fighting the good way. That war was different than the previous ones. It was more a guerilla than a war, making the things much more complex. Politicians thought they could win simply by adding more soldiers and that's exactly what they've done without success. If they had tried to fight differently, perhaps they would have succeeded.
    Now, if I apply this to ORM, I come to a totally different conclusion than Ted's : use a less basic and more clever solution if things are complex.
  24. Funny quote[ Go to top ]

    Ted Neward's very correct observations concern project teams building their own ORM solutions. This is of course insane, and we would never, ever advocate this.That is why people use what we already implemented for them.
    You're only getting part of the message. You're not at all accurately characterizing Ted's overall opinion. He introduced this quote in a session that he teaches with me at the nofluffjuststuff.com symposiums. He was referring to the Microsoft object spaces, which has once again been delayed. Ted is very clear: ORM solutions, both commercial and home grown, open up a whole lot of problems for the typical user. They can potentially be very messy and dangerous, and once in, you cannot easily extract yourself.

    I can see why he made these observations. I've often made a similar analogy in my classes. The persistence landscape, like Viet Nam, is dotted with battlefields and the burnt out hulks of frameworks that tried and failed to achieve commercial success. Customers too have long-lasting scars. Hibernate had a whole lot to do with changing that perception.

    Personally, I think Ted's ideas in this area are a little outdated. ORM technology has improved dramatically. For just one example, you can now easily set a lazy/eager strategy per scenario, as needed, with Kodo, and you can have the management tools tell you when an eager association might be a good one, in a given context.

    I also think that the abstraction layers of frameworks like Spring make it much easier to isolate the impact of a given ORM solution. This can minimize the cost of your "exit strategy". Colin's given an example of moving between IBatis and Hibernate, and even letting them coexist. I also have customers who believe that they might want to move from one solution to another. With Spring, the usage model between something like JDO and Hibernate is very similar, and potentially very well isolated.

    But it's clear to me that you and Ted are making very different points.
  25. bulk operations[ Go to top ]

    Hmmm. Joshua Davis. Sounds familiar.
  26. Hi, All,

    I'm not so sure if it has the same purpose, but I think that Cayenne ORM already has a feature like that. It is called "SQLTemplate" and can be done by the GUI (CayenneModeler) too. Very easy and useful.

          ______
         /_____/ \
        /____ / \
       /_____/_ \
      /_____/ | \ _\
     /_____/ º| \/ |\
     \_____\ | >^ </
      \_____\_|_/ \_|
       \_____\ /
        \_____\ /
         \_____\/
  27. Hi, All,I'm not so sure if it has the same purpose, but I think that Cayenne ORM already has a feature like that. It is called "SQLTemplate" and can be done by the GUI (CayenneModeler) too. Very easy and useful.
    Exactly! In my (biased) opinion SQLTemplates is one of the most powerful such tools in Java. Like iBatis we recognize that building dynamic SQL in the code is not easy (e.g. changing the number of parameters in the WHERE clause can significantly change query semantics). Unlike iBatis we decided against using XML for scripting, and instead offer custom Velocity macros. This makes templates much easier to use and understand.

    And of course this feature can hitch to Cayenne powerful access stack, so dynamic query can be loaded from the mapping created in the Modeler, query will be routed to the correct database, and we even allow to have multiple SQL "flavors" for the same query to make it compatible with more than one type of DB.

    Andrus
  28. iBATIS[ Go to top ]

    My 2 (euro)cents. I didn't knew iBatis and I've checked the (nicely written) documentation. Sorry, but I don't understand where is the real added value of such a framework except, perhaps, that if used by many developers it could become a kind of standard framework for JDBC. I've worked on different projects that were using a lot of JDBC statements and on all of them we had something similar to iBatis to move the SQL statements out of the java code. I'm sure most companies do as well. I could eventually use it to replace some part of the homegrown code, but the added value of an ORM tool like Hibernate is much more interesting (at least for the kind of projects I usually work on). If you only need one or two statements that could use iBatis in your project, I wonder if it's really useful to add another framework. Therefore the solution proposed by Gavin is interesting. Also, I'm sure the next releases of Hibernate will improve on this.
  29. iBATIS[ Go to top ]

    is a great tool, simple but advanced.

    I used in in project where other programmers had small/none JDBC knowledge and modelling with objects was not appropriate. After short introduction they were able to write their SQL commands in iBatis config xml files and populate HashMap with values and pass them to iBatis (or extract values from Map). The productivity was amazing.
  30. iBATIS[ Go to top ]

    is a great tool, simple but advanced.I used in in project where other programmers had small/none JDBC knowledge and modelling with objects was not appropriate. After short introduction they were able to write their SQL commands in iBatis config xml files and populate HashMap with values and pass them to iBatis (or extract values from Map). The productivity was amazing.
    I wonder how the maintain ability is? I am currently maintaining a couple of projects that use such a framework - and the maintainability is horrible.

    :(
  31. is a great tool, simple but advanced.I used in in project where other programmers had small/none JDBC knowledge and modelling with objects was not appropriate. After short introduction they were able to write their SQL commands in iBatis config xml files and populate HashMap with values and pass them to iBatis (or extract values from Map). The productivity was amazing.
    I wonder how the maintain ability is? I am currently maintaining a couple of projects that use such a framework - and the maintainability is horrible.:(
    Mark,

    Why is it so? Can you give us some concrete examples of iBatis being horrible
    to maintain. While I find iBatis less comprehensive then Hibernate, I am not
    sure that it is horrible. Maybe some good examples would convince me so before
    I stray into a iBatis waters. I know that iBatis works very nicely with Spring.

    Regards,
    Edmon
  32. Edmon,
     I wasn't directly refering to iBatis. I've not used it and only glanced at it. But it seems that for each sql, you put it in xml . Unlike Hibernate where the mapping file handles it. That limits your exposure. If a change is made to the db or java object then you have to, via string search, find all the places where the value is changed or affected.

     If this isn't what iBatis does - sorry. I was refering more to the post and what is seemed to say. I've had to deal with this on a day-to-day basis (since we last saw each other) and it is not good. (On that note, anyone who thinks xsl is great for creating web app UIs - same issue.)

    Mark
  33. iBATIS[ Go to top ]

    It is a good solution when you have to interface with stored procedures and/or a legacy database.
  34. Lets focus on something else[ Go to top ]

    Hi,
      I think java guyz are concentrating too much on patterns and frameworks ... is any one really thinking of the performance beating it took in the recent tss survey... come on guyz lets focus on java performance .... thats crucial ... we can have tons of frameworks .. but if the performance is bad .. java is gonna die ....
  35. Lets focus on something else[ Go to top ]

    Hi, I think java guyz are concentrating too much on patterns and frameworks ... is any one really thinking of the performance beating it took in the recent tss survey... come on guyz lets focus on java performance .... thats crucial ... we can have tons of frameworks .. but the performance is bad .. java is gonna die ....
    Let's all say it together "Code for maintainability ...".

    Also, "Speed kills" (Ok, that has to do with automobiles but it applies).

    BTW, it is not just Java guys "concentrating" on Frameworks/patterns. It is also going on in the "other" world.
  36. Thin ice[ Go to top ]

    With the risk of not being taken seriously by the 'J2EE world' I feel the need to ask the following question.

    Why aren't we using the power/performance and functionality the underlying database is providing us?

    I'm biased I know, because we're predominantly using Oracle databases in projects. In a lot of those projects this database has already been there for quite a while and customers have invested lots of money in utilizing things like stored procedures, triggers and stuff. A thin layer of clean JDBC code in most cases is sufficient to do everything we want to do with the data and is super fast. I haven't used Hibernate (yet), but have used TopLink and Oracle's ADF Business Services (fka BC4J Framework) and sure these frameworks let you bridge the O/R gap. But sometimes I wonder whether this is actually helps me in building well performing applications or just cleanly designed ones (that don't perform).
  37. Thin ice[ Go to top ]

    With the risk of not being taken seriously by the 'J2EE world' I feel the need to ask the following question.Why aren't we using the power/performance and functionality the underlying database is providing us?
    But sometimes I wonder whether this is actually helps me in building well performing applications or just cleanly designed ones (that don't perform).
    Those data access frameworks are not just done to design cleanly. Their goal is multiple. Here are a few ideas I directly think about :
    - make the application live longer by resisting to changes in the DB layer. What happens if, for whatever reason, your company suddenly decide to switch to another DB vendor ? To name a few possible reasons : price increase for the support, DB vendor bought by another company and support discontinued, functionalities needed for another project and not available with that product but your company wants to pay only once for the support, product outdated and, while your company has grown and need more people for some new developments, it cannot easily find knowledgeable people on the market for that "old" product, ...
    - make the application less bug prone. Using a framework used and tested by many others, you're sure it will have less bug than if you develop everything yourself. And if you encounter a bug in the framework, it's probably already been fixed by someone else. If you start without a framework and your application is large, at the end you'll have developed your own homegrown framework. That framework will hardly be as good as a public framework is and when new developers will join your team, they'll have to learn it. If you take a public framework, you just have to be sure the new employee has sound experience of this public framework.
    - develop faster (only true if the frameworks are the right ones for your project) and make the code easier to maintain.
    - for ORM tools, some other reasons are, as you suggest, the O/R impedance mismatch, but also the need, especially in three-tiers architecture, to cache data in the business tier (mainly for performance reasons). Also, these tools often produce better SQL for your DB than you would (except if you're a true DB expert, but it becomes difficult to be both a DB expert and a Java expert) and, at least, it produces it faster than you would.

    There are probably many other reasons, but this is just what came directly to my mind.
  38. Thin ice[ Go to top ]

    What happens if, for whatever reason, your company suddenly decide to switch to another DB vendor ?
    I'd counter by saying that a switch from Oracle to a.n.other db should be painful. The huge database vendors have placed in loads of features and optimisations that differentiate themselves from each other. If you spend vast amounts on licensing them then you should try to use at least some of their amazing features. Don't simply use vanilla stuff.

    This argument breaks down if you are a vendor selling to multiple organisations - at which point multi db vendor support becomes vital, and I start to agree with you.
    Using a framework used and tested by many others, you're sure it will have less bug than if you develop everything yourself. And if you encounter a bug in the framework, it's probably already been fixed by someone else.
    The issue here is that the frameworks you choose are themselves very young. Written by small teams who want to get rich off consultancy. And totally tied to fashion - jakarta avalon, pico, jboss, spring, struts, tapestry, velocity, hibernate, etc. etc.

    Just because it's called a framework does not mean its any good, has longevity or is worth poluting your code base for.
    at the end you'll have developed your own homegrown framework. That framework will hardly be as good as a public framework is and when new developers will join your team, they'll have to learn it.
    The generic frameworks start simple, grow to embrace the world, and become bloatware. Fine, if you want to learn their mantras and incantations off by heart you can achieve anything, but you don't want to achieve anything. You want a achieve a solution to your current problem.

    It is, in fact, very appropriate to develop a custom solution for a custom problem. Just make sure you don't then try to make your custom solution a company standard - because then you are into framework land, and again I agree with your comments.

    Cheers,
    Jonathan
    Emeraldjb - yes it's green, and it does DAO.
  39. Thin ice[ Go to top ]

    I'd counter by saying that a switch from Oracle to a.n.other db should be painful.
    ... ! Why has the ANSI comittee spent so much time on defining SQL then. It would have made it even more difficult without their contribution. Too bad. ;-)
    The huge database vendors have placed in loads of features and optimisations that differentiate themselves from each other. If you spend vast amounts on licensing them then you should try to use at least some of their amazing features.
    The frameworks don't prevent using amazing and wonderful features of your DB. If you define a view or a stored proc, it's still possible to access it from your code. But these amazing features also have their own issues and using them everywhere is probably not the best choice ... except of course if you're an expert in one DB product and want to save your job.
    Using a framework used and tested by many others, you're sure it will have less bug than if you develop everything yourself. And if you encounter a bug in the framework, it's probably already been fixed by someone else.
    The issue here is that the frameworks you choose are themselves very young. Written by small teams who want to get rich off consultancy.
    The popular open source frameworks are by no mean written by small teams. They're written by people that are using them on a daily basis on their projects in companies they work for (and not only in the consultancy sector). Therefore they can be young in the time; they're mature in use (and probably much more than some technologies sold at big prices that get quicker acceptance in many companies).
    Just because it's called a framework does not mean its any good, has longevity or is worth poluting your code base for.
    I totally agree on this point. The good framework in the good place. It must be tested to check if it match the requirements of the project and well understood before being included on any project in a company. For the longevity, if the source code is available and understood by the people in the project, I don't see the problem.
    Fine, if you want to learn their mantras and incantations off by heart you can achieve anything, but you don't want to achieve anything. You want a achieve a solution to your current problem.
    Fine. That's the goal of most frameworks : concentrate on your business functionalities.
  40. Thin ice[ Go to top ]

    Fine. That's the goal of most frameworks : concentrate on your business functionalities.
    And when there IS a real performance problem you will have time spend concentrating on it.

    In support of your previous statements - http://www.computerworld.com/managementtopics/management/story/0,10801,95395,00.html
  41. Hibernate may be an overall great framework but when you really start wondering what it really is great at then you know something is wrong. Before I go jumping all over the place, I want to highlight on certain comments and quotes that people have said (inc the author) in favor of HQL.: The Author of the article Wrote: "... not only because the overwhelming bulk of SQL code needed by most applications is of the tedious kind, and simply does not require human intervention, but also because a JDBC framework operates at a different semantic level to ORM. A solution like iBATIS knows a lot less about the semantics of the SQL it is issuing, and of the resulting datasets. This means that there is much less opportunity for performance optimizations such as effficent caching. (By "efficient", I am referring mainly to efficient cache invalidation strategies, which are crucial to the usefulness of the cache.)..." What wrong with the above, well nothing really and everything, to start with it reflects the perspective of the writer and supporters of HQL. 1. In a professional environment, you do not have the devloper sitting and optimizing queries, its the DBA or the PL/SQL devs. And quess what they understand best... SQL not HQL. You cannot ask a DBA to performance tune an HQL query. If one does, its by coincidence. 2. When languages like HQL, prev. EJB QL etc come, they create a paralell world. The learning curve is a mixed bag of both worlds, which is actually bad and wrong. This is why IBatis is popular, what I like about IBatis is it is Focussed. the author talks about things where IBatis lacks; well the fact is there are other ways to do that and better than Hibernate and IBatis need not and does not focus on them. Hibernate is generally good, ...only "generally". 3. Pro HQL arguments hold true for environments where develoers want to do it all, where the difference between a SWare developer and a database programmer or DBA is not understood, which does not hold true in professional large scale outfits. Note: I'm not sayin Hibernate does not suit a lare scale outfit, but the attack is solely on HQL in this point of mine. 4. Regarding performance, native JDBC batch/bulk update is much faster than Hibernate. lets not even compare, I know this because of a project for Telecom and we used Hibernate and had to introduce native JDBC also for performance reasons. Except for SQL living in an XML hibernate's role was reduced with time as the hype died and inspite of Hibernate versions improving. Also, database caching with second level caching independently can go beyond what Hibernate offers in one box. 5. Hibrenate is a framework, not a technology. What they need to do is really thin up the way things are done. There are too many ways of doing the same thing and each is restricted in some sense. Again, the framework is 'Good overall but lacks focus'; again in specialized Apps you quickly realize "Good overall" means nothing and one size fits all it is a trap. The difference in 'Framework' vs 'Technology' is that investment in a learning curve for a framework should be less compared to tech. Everyone would want to master Java and/or PL/SQL, but if to get things done in Hiberate that I can do in JDBC I need the same or a higher learning curve, it is simply not worth it. True, Hibernate takes care of a lot of things if one had to program, but the question is "what % of that do you really need and in return what is the cost of learning to do that"? 6. Because of the conceptual difference between ORM and Relational databases; there are situations where you suddenly wish you could write an SQL. 7. In ragard to the post I'm replying: "Posted by: Jonathan Gibbons on August 26, 2004 in response to Message #135707 What happens if, for whatever reason, your company suddenly decide to switch to another DB vendor ? I'd counter by saying that a switch from Oracle to a.n.other db should be painful." ...Untrue, the prodcuts that I've worked on had to be shipped to multiple vendors with diffrent DB's. If the deisng is good, porting is not painful. Infact HQL is not even equipped to handle all the possibilities that ORACLE can provide. Also, if a client uses ORACLE ,should the software be able to leverage the benifits that the DB is offering?? There is a way to port DB specific SQL and yet be platform neutral in ways way superior to using HQL. The concept is simialar to PolyMorphism but at an SQL level. Dynamically bind maps to the DAO. Wish I could go more in detail but I know by experience this is far superior to using HQL. Again, you cannot tell the client "Well we work on your database but sorry you spent a million on it while we can only use 20% of its capabilities and we also dont have DBA's because our developers optimize using HQL". .. In organization who really wish to scale or grow, this should not happen. ..Yes, HQL is convenient and lets leave it at that. Its good for programming perhaps but I believe its bad practice for software engineering.
  42. Hibernate's half baked solution[ Go to top ]

    ..well continuing my previous thread message. I wanted to shift from philosophy to a concrete example. consider this; Hibernate allows you to define SQL queries in an XML. (Nice so far); but you cannot define dynamic SQL's in XML. So because of a limitation of Hibernate; and it would be bad practice to scatter ones queries I devised a simple yet elegant way to derive the query from the XML and simply replace the dynamic part as a string parameter. So create a new dynamic SQLQuery object basedo on the previous one. But then, you also need to define the SCALAR's for a SQLQuery. The scalars are PRIVATE. ..My point is, the designer put in the ability to put use SQL and not Dynamic SQL and then also make the interfaces non accessable and worse non-extendible. Weh ndesigning frameworks, it is impssoble to comrehend al lthe usa cases, that is why the use of portected methods or even Spring for such usage should be enouraged. ...Its simple logic, the more one tries to do with a framework there will be more restrictions and complications. Again, if there was a way to do it, who has the time when it can be done so easily throught ligter frameworks or JDBC. ..Bottom line Hibernate tries to do too much and it is only fit for small apps that are built on stable/statiic DB schemas that too in Form/Insert scenarios. ..Real world, commercial large scale applications, ...i wouldnt vote for it.
  43. Thin ice[ Go to top ]

    Their goal is multiple. Here are a few ideas I directly think about :- make the application live longer by resisting to changes in the DB layer. What happens if, for whatever reason, your company suddenly decide to switch to another DB vendor ? To name a few possible reasons : price increase for the support, DB vendor bought by another company and support discontinued, functionalities needed ...
    This is not a good reason to hide database, it lives longer than any framework(see EJB and JDO versions).
    Most architects can not understand abstractions and prefer to draw "objects" and good reason to use O/R tool is to abstrast model by transforming it to more abstract ralational model.
  44. Thin ice[ Go to top ]

    This is not a good reason to hide database, it lives longer than any framework(see EJB and JDO versions).
    It's not about hiding the database. It's about improving the ways to access it.
  45. Thin ice[ Go to top ]

    make the application live longer by resisting to changes in the DB layer.
    This is not a good reason to hide database, it lives longer than any framework(see EJB and JDO versions).
    I was once told "You can do whatever you want to your customers applications, just don't play with their data"

    I've seen Oracle instances survived VBX/COM/EJB/POJO/.Net/"next big thing" development over the years.


    Cheers
  46. Thin ice[ Go to top ]

    With the risk of not being taken seriously by the 'J2EE world' I feel the need to ask the following question.Why aren't we using the power/performance and functionality the underlying database is providing us?
    But sometimes I wonder whether this is actually helps me in building well performing applications or just cleanly designed ones (that don't perform).
    Those data access frameworks are not just done to design cleanly. Their goal is multiple. Here are a few ideas I directly think about :- make the application live longer by resisting to changes in the DB layer. What happens if, for whatever reason, your company suddenly decide to switch to another DB vendor ?
    Very unlikely. The access methods (xDBC/DAO/EJB/JDO) can change, the programming language and platform can change, but the underlying database... nah, very unlikely.

    For large projects and shared database there is no choice as to use database built-in features. For boxed apps with bundled "private" database it may be better to define all code on the client, thus the database can be easily changed or upgraded. Everything is relative in DB world ;)
  47. Thin ice[ Go to top ]

    Very unlikely.
    I've been at two places in the last two years where we changed the db or were contemplating it. Both large companies. One cause the db we were using didn't perform (MySQL performed better) and one cause they became partners with a large Vendor.
     The access methods (xDBC/DAO/EJB/JDO) can change, the programming language and platform can change, but the underlying database... nah, very unlikely.
    Only because applications are typically written in such a way to make it very expensive. And usually this is not necessary.
    For large projects and shared database there is no choice as to use database built-in features.
    There isn't? Might wanna look around. As for shared databases - not a good idea. For the very reason you describe.
    For boxed apps with bundled "private" database it may be better to define all code on the client, thus the database can be easily changed or upgraded.
    On the client? It can be in "client" code but doesn't necessarily need to be on the client. It could run on the db server thus negating the network issue.

    The issue here is a matter or presuppositions. Most who are looking at O/R M solutions are staring with the belief that the db is a place to persist non-transient objects. Those who want to use stored procs, etc start with the db being the central point for an application or (worse yet) multiple applications.
  48. Thin ice[ Go to top ]

    Most who are looking at O/R M solutions are staring with the belief that the db is a place to persist non-transient objects. Those who want to use stored procs, etc start with the db being the central point for an application or (worse yet) multiple applications.
    Worse, riiight. The "object" guys think that the fancy model and the objects in their application is what should be cared of, and yes, be persisted somewhere, whatever. They they get stuck with performance problems and transaction issues and start paying more attention to the database. Then they (or someone else) decides to access the same data from another application and the whole business layer has to be either ported or written again, or just dumped to the database. Eventually they realize that they should have started from the database at the first place.

    The "database" guys use the database as the cornerstone of their system from the very beginning, and develop their object model with respect to proven relational data structure. The database is designed flexible enough to be used by other apps, and set routines like reports are coded in stored procedures. So, if a client asks to create say Flash app to visualize the reports, the data part is already done.

    You may argue that to use database from another app is an old-fashioned way, that it is much cooler to use CORBA (oops, not cool anymore)/web service/messaging to talk to the application, not to the database. Maybe. But the data is persisted in the database. Another application may not have the same object model anyway, so one of the applications has to do the conversion. So it is just easier to get data right from where it resides, and there are fewer hoops to jump through. If the application is down, there would be no way to access the data using messaging or web service. But if the database is still up (and databases usually more failure-tolerant than apps), then an old-fashioned SELECT would do the job.
  49. Thin ice[ Go to top ]

    The "object" guys...
    The "database" guys...
    Really, hasn't the industry defined this object-relational impedance mismatch enough already? Hey, if *Oracle* was convinced that the data model was the end-all-be-all, then Toplink would never have been created and customers wouldn't be trying to map object hierarchies (that match the business objects better than some normalized DDL) to high-performance DB engines (like has already been well said, have evolved into their particular niche over 20+ years).

    This really all comes down to situational bias, nothing more, nothing less. Database guys have to know their products intimately because they're paid to, AND because modern DB systems are that darned complex. Developers try to think in platform-independant ways because we're paid to (and believe me, I see more database re-platforming than application rewrites, but your corporate environment may differ). Usually developers are the first ones to see new business requirements, having an impact on the data model, not the other way around, and besides, who wants to program to objects with dozens of lookup tables?

    And just to throw it in here, the network and server guys aren't in here blaming the both of us groups for making their lives more challenging. They would be if they only knew... Just a couple of months ago I declined an argument with a server guy berating Java and Oracle people because they always make him buy more memory and SAN storage. His solution? The far superior PHP and MySQL combination...
    With this, I'll definitely agree. None of our massive nightly batch process use ORM DAOs.
    Ahhh. The data shuffle. or the data Hokey Pokey.
    You've got that right. Merging 800,000 records from a MySQL database with 4M+ Oracle records, then matching 65,000 updates in an Informix table. Yee haw, it's a regular data rodeo!
    Scott
  50. Thin ice[ Go to top ]

    Really, hasn't the industry defined this object-relational impedance mismatch enough already?
    Yep. So bring on the post-relational dbs!

    BTW, I've done it both ways. "Old school" and "cool". And am trained (my degree) in the old school. So my ideas come from experiencing both worlds. Not some wet-behind-the-ears, starry eyed, ain't Java cool just graduated junior high kid.
  51. Thin ice[ Go to top ]

    Probably there is no "database" and "object" guys, I was very object oriented before to learn server programming and as more I learn as more I become "database" centrific :) It was not trivial to change this way of thinking after COP stuff on desktop and to become a friend for DBA.

    I am very glad to see new features in Hibernate3 for "database" guys, there are a lot of good use cases for both ways.
  52. Thin ice[ Go to top ]

    Just a couple of months ago I declined an argument with a server guy berating Java and Oracle people because they always make him buy more memory and SAN storage. His solution? The far superior PHP and MySQL combination...
    This is totally off the topic, but I recalled the funny pictures from my childhood. It was a book about space exploration, astronauts, spaceships. The pictures illustrated what different departments would like the spaceship to look like. The engine department of course, wanted to put four engines in the first stage, and one big engine in the second. The aerodynamics department wanted sleek profile, which obviously would not be able to fit the engines. The commercial department wanted to make the ship out of aluminum foil to put bigger payload. The communication department wanted to put an antenna on every inch of the surface. And finally, the technological department. Their image of a spaceship was a wooden log with an stick of dynamite tied to it.
  53. Thin ice[ Go to top ]

    The "database" guys versus the "object" guys? This isn't 1998. I'd have thought that this battle was over. No one "won", I thought that everyone had come to their senses and realized that different approaches are warranted by different situations.

    If, in your situation, the database-centric approach is better, then fine. This probably presumes that you are using a db server like Oracle with a number of proprietary value-add features, that you have an inhouse staff with experience in your db, and you have a lot of legacy applications to support that are database centric. You may also have certain performance requirements that require programming more closely to the database.

    But for a lot of other companies, the database is a commodity, like network bandwidth. It's job is to store data reliably and serve it up fast. That doesn't mean that you have to use the tools that the db vendor provides. The whole set of ORM solutions are designed around the fact that unless you need to use vendor-specific db features or are supporting a legacy application, the object-centric approach offers a huge number of advantages over a database-centric approach. As I mentioned before, a big advantage is the fact that in most cases, an object model more closely approximates a business model because it not only includes data, it also includes behavior. Objects can be a lot "smarter" than data sitting in tables, and you can do a lot more cool things with them. You have to be careful about how you do them, but there's a lot more possible in an object layer, and a lot more tools available that have already solved common problems (like remoting, rules engines, workflow engines, etc.) that an object-centric system can use that a database-centric system would have difficulty with.

    You're also forgetting the fact that not every company doing development is working with a set of back-end databases. A lot of people out there are doing work on products for sale, where they can't force a customer to use one kind of database over another. This is a lot more common than people give credit, and is, to me, the best example of a situation where database portability is a primary concern. A lot of talk in this topic has been about whether people agree or disagree that database migration happens a lot, and I think it's important to recognize that regardless of the answer to that question, there are still a lot of people who are justifiably reliant on database portability.

    I have worked with systems design from both a database an object-centric viewpoint, and I still believe that the long-term benefits in cost, portability, maintainability, ease of development, and available toolsets that the object-centric approach provides FAR outweigh any advantages the database centric approach might have. If performance is an issue, deal with it where it comes up. But don't lock yourself into something just because of the 10% of the 90/10 clause. You can still do things one way in 90% of your application and another, more database-centric way in the other 10%. Unless you're a complete hard-headed zealot, afraid that the "object guys" will be challenging your pretty ERDs and stored procedures, the two approaches can coexist.
  54. Thin ice[ Go to top ]

    But for a lot of other companies, the database is a commodity, like network bandwidth.
    Does this mean, that normalization (which directly affects the way the data is accessed and modified), transaction isolation, permissions mean nothing anymore? To store data in an RDBMS one has to deal with database and relational algebra and SQL.
    It's job is to store data reliably and serve it up fast.
    Right, this is the reason to create good database model. Which would be easier if the database model is created first or at least if object model is created with knowledge of how database works.
    The whole set of ORM solutions are designed around the fact that unless you need to use vendor-specific db features or are supporting a legacy application, the object-centric approach offers a huge number of advantages over a database-centric approach.
    I am not against O/R, I just pointed out that I would start designing the system from the database, because it is easier to create a couple of new classes, than to write tedious joins and unions trying to fit some weird class structure in the Procrustes' Bed of relational database. There should be something that you can apply O/R to. This something is a properly designed database. You can go the opposite way and generate tables on the fly, reflecting the object structure. This would be the "private" database, accessible only through this application. This kind of "dynamic" database cannot be easily restored/recreated using static SQL scripts.
    You're also forgetting the fact that not every company doing development is working with a set of back-end databases. A lot of people out there are doing work on products for sale, where they can't force a customer to use one kind of database over another.
    _I_am _ forgetting this fact? I said exactly the same, that it is better to stick more code in the client for retail database apps, because it gives freedom to switch/upgrade the database and because we sell the application, not the dbms.
    Unless you're a complete hard-headed zealot, afraid that the "object guys" will be challenging your pretty ERDs and stored procedures, the two approaches can coexist.
    Exactly. I did not even think of saying that O/R sucks and should never be used. I just said that I prefer to start the design from the database, so my O/R would not have to jump the hoops. I also said that nothing compares with stored procedures when large sets of data must be processed. But O/R is great for just few objects.

    I am looking forward to upcoming changes in Hibernate, the already available SELECT directly into the object is simple to use and very useful.
  55. Thin ice[ Go to top ]

    The "database" guys versus the "object" guys? This isn't 1998. I'd have thought that this battle was over. No one "won",
    A complex database that is fully normalized, is not performant. There are times the it is necessary to break rules. The same occurs for systems completely designed around a completely clean object oriented approach. There are times when you use a fast lane reader approach, or even worse, just pass a raw rowset to the presentation layer because you just want to show data, not to manipulate it. We shouldn't tie ourselves in one approach or another just for the sake of purity.
    If, in your situation, the database-centric approach is better, then fine. This probably presumes that you are using a db server like Oracle with a number of proprietary value-add features, that you have an inhouse staff with experience in your db, and you have a lot of legacy applications to support that are database centric.
    Totally agree. Even if you're building a completely new application from the ground, if a certain feature of the database makes your live less miserable, not only at development time, but also in the future at mainteinance time, why not to use some database specific and proprietary features. More over, you already paid for those features.
    Objects can be a lot "smarter" than data sitting in tables, and you can do a lot more cool things with them. You have to be careful about how you do them, but there's a lot more possible in an object layer, and a lot more tools available that have already solved common problems (like remoting, rules engines, workflow engines, etc.) that an object-centric system can use that a database-centric system would have difficulty with.
    Yeah! It's much nicer to use and expose objects in your applications screens than raw data, but I hate to have to point out that in development environments built around the notion of recordsets (i.e. Microsoft world), the wealth of grids and databound controls speed a lot your development and mainteinance time, even if you break pure OO principles.
    A lot of talk in this topic has been about whether people agree or disagree that database migration happens a lot, and I think it's important to recognize that regardless of the answer to that question, there are still a lot of people who are justifiably reliant on database portability.
    Although in former posts in this thread I've defended the position about using databases for just "stupid" datastores, I'm very careful in use the minimal amount of code dependant on the database. For example, most of my customers use Oracle as their main database. DB2 comes in second place. You can't count always with an Oracle instance running in your lap-top along with those huge Java IDEs. So we use something smaller, lets say Interbase locally. We reconfigure the datasources in app server and we're running against an Oracle instance in the testing environment. Of course this setup is not possible with databases that support legacy applications.
    You can still do things one way in 90% of your application and another, more database-centric way in the other 10%. Unless you're a complete hard-headed zealot, afraid that the "object guys" will be challenging your pretty ERDs and stored procedures, the two approaches can coexist.
    Hardly an experienced database guy should feel threatened by "object guys". It's simple, as time passes, they have more, no less databases to mantain, more, no less users to support in their databases and more, no less disk space to allocate for their databases.

    By the way, I tend to be more an "object guy" (arrggghhh!) but don't want to turn myself in a fundamentalist zealot.


    Cheers
  56. Thin ice[ Go to top ]

    (i.e. Microsoft world), the wealth of grids and databound controls speed a lot your development and mainteinance time
    If all you are doing is CRUD, maybe. I've used them. If I did more than simple CRUD, it ended up being more work, cause usually it didn't work. I've had databound controls not work on different monitors and resolutions. And as for maintenance - more work.

    I got to the point where I used not databound controls unless it was quick and dirty and I knew I would through it away.
  57. Database Guys vs. Object Guys[ Go to top ]

    You are right up to a point. But that point comes just about where you need to "search" or "query" your objects and you've got too many to loop through them all efficiently. It varies, but I'd say, once you've got more than a hundred or so customers, or orders, or employees, or lineitems, or whatever and you need to know different things about them, its time to push it back to the database. Now, your normal workflow probably won't ever typically pass that point. You'll be wanting 1 customer, with 1 or 2 addresses, and maybe a dozen other attributes and maybe a big fat ordered list or three.

    But when it comes time to do the sales reports, or market analysis, or finding 1 customer in a million who lives in that market, has that promotion, and finding out what his balance due is over purchases for the last two years (and you have lots of other people do similar operations at the same time) -- it doesn't matter that you're dealing with the same objects used in a shopping cart or workflow application... You have to deal with them as sets of data or it just won't get done with any reasonable amount of resources in any reasonable amount of time.
  58. Database Guys vs. Object Guys[ Go to top ]

    Here's an idea: use one approach for one situation, and another for the other situation. Even within the same app. I've been doing that for years. I use hibernate for ORM mainly for CRUD operations, creating pages for routine data entry, and creating pages for data viewing and management. For lists that may accept a lot of parameters, I use a thin wrapper over JDBC that dynamically constructs SQL, similar to what Rolf mentioned. This allows me some control over the sql, which may be important if I need to do unions or control how a weird join is done in order to provide a non-standard search parameter.

    The point is that the two approaches can coexist nicely. It's not an all-or-nothing thing. I certainly don't want to write a bunch of SQL unless I have to, and if I have to, I want full control. It looks like Hibernate is getting to where it can support all of that. Regardless of whether you use Hibernate for everything, though, that's not the issue. I think people get so fired up about one way of doing things that they get completely resistant to any other way. The smart way of doing things is to use the right tool for the right job, and realize that any job of complexity may require more than one tool.
  59. Drew,
    I use hibernate for ORM mainly for CRUD operations, creating pages for routine data entry, and creating pages for data viewing and management
    If the reason for using Hibernate is only to save some time-consuming, boring work you can just as well use a code generator (CodeSmith). But as I said before, I can understand the "Quick and Dirty" side of the matter.
    I think people get so fired up about one way of doing things that they get completely resistant to any other way.
    To sum up, I see the following advantages of Dynamic SQL

    1) Total control over the SQL. (Other people see this as a disadvantage- I know :)

    2) Smaller and faster applications. (Less lines of code).

    3) In the thin wrapper that dynamically constructs SQL I can add role-based security and system-wide last-minute restrictions to the SQL.

    4) For the same reason as above (because I have one central point where all SQL passes through) I can have automatic, generic audit trail generation. (Who changed the field, when, beforevalue, aftervalue, etc, for security and replication)

    5) I always act only upon the relevant columns, no UPDATE of all fields when the user has changed only one single field, no SELECT * FROM Foo and so on.

    Regards
    Rolf Tollerud
  60. Static SQL has all same 5 advantages too, auditing, security, query transformation rules, triggers, validation are implemented in RDBMS, you do not need to do it in application, but it is more popular to reinvent it than to learn.
    RDBMS has all features to work with data, it is very mature technology, there are many Open Souce RDBMS implementations for enterprice, there is almost nothing to invent more.
    The main point in this way is help for DBA, hi maintains our toys and databases, it is very useful for "large" and "complex" systems aka "enteprise system". Same features can be reused by any connectivity, JAVA, C#, Perl or report generator. "Complex object graph" work for toys only, just our understanding is different about toys. IMO RDBMS "portability" motivation is very silly for real "enterprice" system.
  61. Sometimes I despair of explaining.

    Juozas:
    Static SQL has all same 5 advantages too, auditing, security, query transformation rules, triggers, validation are implemented in RDBMS, you do not need to do it in application, but it is more popular to reinvent it than to learn.
    But then you have given up the option to change database! Also read the original link for an exposé of all the problems with stored procedures.
    (http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx)

    With Dynamic SQL you have the same freedom to change the database from for instance MySQL to Oracle as you have with Hibernate. You are database independent.

    The Datalayer is divided into two layers remember? One database dependent, one generic. To change to another database you just swap the object most close to the database. (150-200 lines of code). If you have kept to ANSI SQL there are very few problems. (Especially if you have brains enough to save the date-fields in String ISO format :)

    Regards
    Rolf Tollerud
  62. Yes, dynamic SQL has use cases for toys and migration problem exists for toys only, serious systems never migrate form MySQL to Oracle or from Oracle to MySQL.
    Student can do this misstake, but if system analyst designs this kind of system then fire him, he doe's not understand difference between MySQL and Oracle.
  63. "serious systems never migrate form MySQL to Oracle or from Oracle to MySQL"

    Is that so? In that case there is no use discussing any further then, is it?

    My God, Santa Maria!
  64. We can continue to discuss about toys, it is interesting too and probably market is larger for simple, user friendly applications than for monsters on mainframe.
  65. But I never work with toys. When we deliver a shrink-wrapped product, for instance a CRM system, the same server-side-stateless application without any modification is used by the little office with 2-3 users as well as the Internet version with ten of thousands or even millions of users.

    All depends on the database-setup behind. As I said, there is a big difference between products and contract projects.

    Regards
    Rolf Tollerud
  66. I work with both and there is no shame to implement a toy, it is not the same to develop cool home pages with javascript too, I have saw WYSIWYG html editor implemented with javascript, It needs more work than "mission critical" system.
  67. So according to you SAP a toy too, because it is build with Dynamic SQL?
    And please do not tell me that SAP is crap :) I have defended US many times before but the worlds best programmers lives in Russia IMO. But the worlds best software is build in Germany. (Deutsche gründlicheit" - German thouroghness).

    Sorry
    Rolf Tollerud
  68. I do not know about SAP, it is not very popular in our country at this time.
    So according to you SAP a toy too, because it is build with Dynamic SQL?And please do not tell me that SAP is crap :) I have defended US many times before but the worlds best programmers lives in Russia IMO. But the worlds best software is build in Germany. (Deutsche gründlicheit" - German thouroghness).SorryRolf Tollerud
  69. So according to you SAP a toy too, because it is build with Dynamic SQL?And please do not tell me that SAP is crap :)
    Good example, Rolf. I would add, for those who argue that serious software never switch to another DB, that SAP is going to switch from its homegrown Adabas based DB to a clustered 64-bit DB based on MySql.
    I have defended US many times before but the worlds best programmers lives in Russia IMO. But the worlds best software is build in Germany. (Deutsche gründlicheit" - German thouroghness).
    Sorry, but I cannot agree on that. There are good and bad developers all around the world, in every country. I've worked both with good and bad developers from a lot of countries, including Russia and Germany.
  70. Good example, Rolf. I would add, for those who argue that serious software never switch to another DB, that SAP is going to switch from its homegrown Adabas based DB to a clustered 64-bit DB based on MySql.
    http://www.mysql.com/products/maxdb/ Is not the same database with different name ? As I understand it is backwards than you are talking.
  71. http://www.mysql.com/products/maxdb/ Is not the same database with different name ? As I understand it is backwards than you are talking.
    No. That one is the previous one. It was primarily developped by SAP and supported and improver by MySQL AB since the agreement between the two companies last year. Have a look at http://www.linuxworld.com.au/index.php/id;380441264;fp;4;fpid;3 for the new one (MaxDB 7.6), completely developed by MySQL.
  72. http://www.mysql.com/products/maxdb/ Is not the same database with different name ? As I understand it is backwards than you are talking.
    No. That one is the previous one. It was primarily developped by SAP and supported and improver by MySQL AB since the agreement between the two companies last year. Have a look at http://www.linuxworld.com.au/index.php/id;380441264;fp;4;fpid;3 for the new one (MaxDB 7.6), completely developed by MySQL.
    It is hard to understand how it proves Rolf point, looks like there is no migration, it is just a rename of the same code Adabas == SapDB == MaxDB, is not it ?
     
    "It is targetted for large mySAP Business Suite environments and other applications that require maximum enterprise-level database functionality and complements the MySQL database server."

    One of us is confused by this rebranding.

    http://sapdb.org/

    "SAP DB has become MaxDB"

    How do you understand it ?

    I understand it as MySQL toy database is dead and there is nothing to migrate to.
  73. "It is hard to understand how it proves Rolf point"

    My point is only that it is important to have the option to change the database. If MySQL is a toy or not have absolutely nothing to do with it.

    But well-meaning impractical theorists can never distinguish between what is the point and what is not the point.

    Why don't you go back and continue with your large Weblogic/Websphere project with dozens of Entity beans for the little music shop on the corner! You have to watch out so it won’t look like a toy ;)

    Regards
    Rolf Tollerud
  74. looks like there is no migration, it is just a rename of the same code Adabas == SapDB == MaxDB, is not it ?
    Again, no. Is it so hard to understand ? The right equation is : "Adabas == SapDB == MaxDB until version 7.5". From version 7.6, "MaxDB = MySQL engine + support for compatibility with previous versions, 64-bit, clustering, ...".
    I understand it as MySQL toy database is dead and there is nothing to migrate to.
    ??? Hard to believe. How do you come to this conclusion ?
  75. As I said, there is a big differene between products and contract projects.
    Having done both, I don't believe there is. The issue/problem is that people think there is. And so they are developed that way. So until that mindset changes - monolithic, difficult to change, expensive "applications" will continue to be developed.
  76. "Not invented here"[ Go to top ]

    Allow me to laugh. IMO there are impossible to have something that:

    Look like crap, perform as crap, have a crap uptime and not even is finished,
    Without also actually be crap.
    there is a big difference between products and contract projects.
    Mark:"The issue/problem is that people think there is"

    No the issue/problem is that people think there isn't". One of the most stupid thing you can do in this world is to built software yourself instead of buying of-the-shelf products.

    "IT-Contractors, used-car salesmen and horse-thieves"

    Regards
    Rolf Tollerud
  77. P.S.[ Go to top ]

    How the typical IT-contractor manage to stay out of jail is a constant amazement to me.
  78. "Not invented here"[ Go to top ]

    I'm sorry you've had bad experiences with contractors. I'm not one of them. I do care about my clients and their projects. Sometimes too much.

    What I have seen is that the reason the "application" ends up being crap is not always the consultant/contractors fault (in my experience, usually not). If the contractor has an external agenda (selling his/her software or hardware) then beware. I have seen plenty of third party/off the shelf software be crap. I've done lost of integrating with it. Very difficult because it was basically "closed" software.


    I guess you didn't understand my comment. I meant that people think if you build it for your self (or someone else - custom software) it should be build totally different than off-the-shelf software. They should be of the same high quality and flexibility.

    Building something for yourself is not stupid. I've not come across any (business application type) software that was good enough by itself unless it was meant to stand alone. Unfortunately, no software is an island.

    Like I've said, I've done and still do both.
  79. how many copies did you sell[ Go to top ]

    I do not believe you have and I shall explain why you may think so.

    That a product is a more hardened and robust piece of work has nothing to do with myth and magic, it is only a direct consequence of that approximately 100X as much money, time and resources is allocated to those products compared with consulting projects. In addition you have persons with specialist knowledge of the business area involved and lots of input and back-reporting from all the customers over the years. In short these successful products are often a labor of love bordering to art. But then I am of course talking of real product companies with thousands of copies of their software sold.

    On the other hand, there is something which I would call "consult products”, which is the results of ordinary contract consult company get hubris and try to make a product from some godforsaken project. If you look close enough you will find that almost every consult company has at least one such skeleton in the wardrobe.

    I once was on first row to watch such a project. The company was Enator with 1200 employees, Apple Sweden and Handelsbanken, one of the largest banks in Scandinavia. They were to build a Customer Loyalty Program. Five million dollars was allocated, everything was done by the book (the Waterfall method, documentation, planning you name it, etc) and so on, and the result? The product was finished and called "Mathilda" but have until this date not sold a single copy.

    The moral is: Consult companies have absolutely no understanding or any idea whatsoever of how much more work it is to make a product compared to consulting. When you say that you have been working with products I think that is must have been one of those kinds of projects. Or how many copies did you sell?

    Or do you think that the above mentioned companies would have succeeded making "Spring"? :)

    Regards
    Rolf Tollerud
  80. Get rid of the database![ Go to top ]

    ... Along with the database guys and the object guys.

    And start writing hard disk manipulation functions in C again to handle your data persistency! And you should get max performance.

    I believe this kind of performance arguments were abundant when SQL relational databases were in their early days. The same kind of performance arguments were debated in the dawm of OOP era.

    Today more and more apps use relational databases while fewer and fewer need to write native I/O codes, but they will never replace each other.

    The same will be true for O/R tools whether you like it now or not. More and more apps will be using O/R tools while fewer and fewer will base on plaint SQL and stored procedures, but they will never replace each other.

    History always repeats.

    But we should keep arguing for sport of it.
  81. Get rid of the database![ Go to top ]

    You are wrong about databases and SQL, O/R is a step back to programmic data access, SQL is declarative query langue and it is nothing more, there are a lot of ways to extend it and to make it more programmable, but It is not a good idea to do it on client side (it is easy, but crappy). It is better to buy some book about SQL and database than try to ignore it, ignorance can not help to solve any problems.
    This kind client side mapping solutions for JAVA language can be usefull for some toys, but all solutions are good for toys (PHP is the best).
  82. Get rid of the database[ Go to top ]

    I think you missunderstood the last comment about Getting rid of the database.

    The idea posted was simple. If you want high performance, write assembly code...
    Why only a few people do that; Convenience.

    Why there are so many tools and compilers in the market; Convenience.


    In my point of view, those arguments have goint out of the scope here. If one fews confortable with a tool(toy or not), she is efficient, it is possible to quickly train others(nobody knows if she is gonna die next day or not). Then she must use the tool.

    I 've been working with java for some years, but, I have friends that also can produce quality code using microsoft stuff. What is the point? they make money, and I make money too. Good for them, good for me. We still friends. They use whatever is convenient for them.


    If you like to write SQL keep doing it. If you like hibernate. Good keep on going. Just write good code/software
  83. Get rid of the database[ Go to top ]

    I think you missunderstood the last comment about Getting rid of the database.

    The idea posted was simple. If you want high performance, write assembly code...
    Why only a few people do that; Convenience.

    Why there are so many tools and compilers in the market; Convenience.


    In my point of view, those arguments have goint out of the scope here. If one fews confortable with a tool(toy or not), she is efficient, it is possible to quickly train others(nobody knows if she is gonna die next day or not). Then she must use the tool.

    I 've been working with java for some years, but, I have friends that also can produce quality code using microsoft stuff. What is the point? they make money, and I make money too. Good for them, good for me. We still friends. They use whatever is convenient for them.


    If you like to write SQL keep doing it. If you like hibernate. Good keep on going. Just write good code/software
  84. Get rid of the database[ Go to top ]

    I think you missunderstood the last comment about Getting rid of the database.

    The idea posted was simple. If you want high performance, write assembly code...
    Why only a few people do that; Convenience.

    Why there are so many tools and compilers in the market; Convenience.


    In my point of view, those arguments have goint out of the scope here. If one fews confortable with a tool(toy or not), she is efficient, it is possible to quickly train others(nobody knows if she is gonna die next day or not). Then she must use the tool.

    I 've been working with java for some years, but, I have friends that also can produce quality code using microsoft stuff. What is the point? they make money, and I make money too. Good for them, good for me. We still friends. They use whatever is convenient for them.


    If you like to write SQL keep doing it. If you like hibernate. Good keep on going. Just write good code/software
  85. Thin ice[ Go to top ]

    Very unlikely.
    I've been at two places in the last two years where we changed the db or were contemplating it.
    I think this is a situation where you should evaluate on a case by case base. Lets say your customer owns a big iron IBM mainframe, with tons of COBOL code depending on features unique to DB2. The switch is very unlikely. Also for customers that have ERP systems working on Oracle databases. In those cases is very unlikely to see a switch in database vendors. For sure someone could cite a case, but how often this occur considering the total universe of applications?
    Most who are looking at O/R M solutions are staring with the belief that the db is a place to persist non-transient objects. Those who want to use stored procs, etc start with the db being the central point for an application or (worse yet) multiple applications.
    That's right, there are a lot of supositions. For example, that you're building all of your corporate applications using OOP. If you don't, then the assumption that the database is just for storing non-transient objects falls. But it would be true that the database is the central point for all the applications.

    Cheers
  86. Thin ice[ Go to top ]

    Lets say your customer owns a big iron IBM mainframe, with tons of COBOL code depending on features unique to DB2. The switch is very unlikely.
    More than unlikely. I don't know of any other relation db that runs on Big Iron. Oracle? The SQL statements in COBOL are specific the to the db.

    But guess how most (a lot of?) "data" of legacy sysmtem like this accessed. Via existing transactions. Reusing existing business logic existing in CICS, IMS (not the db), Natural and some others. Tough if the application is accessed via TSO.


    <blockquotes>
     For example, that you're building all of your corporate applications using OOP.
     If you don't, then the assumption that the database is just for storing non-transient objects falls.
    </blockquotes>
    Sure does when you don't have objects to persist.
    For sure someone could cite a case, but how often this occur considering the total universe of applications?
    If the application "tied" to a db. seldom. Alot of applications are written that way. And with the volume of "legacy" apps and VB apps out there - I would venture a guess to say most can't (can't means a bascially a rewrite would be needed). Not that "modern" apps couldn't be if written differently.
  87. Thin ice[ Go to top ]

    Those data access frameworks are not just done to design cleanly. Their goal is multiple. Here are a few ideas I directly think about :- make the application live longer by resisting to changes in the DB layer. What happens if, for whatever reason, your company suddenly decide to switch to another DB vendor ?Very unlikely. The access methods (xDBC/DAO/EJB/JDO) can change, the programming language and platform can change, but the underlying database... nah, very unlikely.How comes then than I'm currently working on such a project ? Migration from Adabas to Oracle. And this is not my first project like that. A lot of companies regularly change their DBMS system. Perhaps not the dinosaur companies, because they're tied to their DBMS engine : they've too much DB specific artifacts in their system to even think about it.
  88. Thin ice[ Go to top ]

    Why aren't we using the power/performance and functionality the underlying database is providing us?
    A good question. I've worked in investment banking environments where DBAs don't even permit SELECT/INSERT/UPDATE/DELETE - everything must be done via stored procs in the production environment. Trivializing or ignoring the database seems to be quite common in Javaland, but in my experience a well thought out database design always pays dividends in performance and maintainability.
  89. Thin ice[ Go to top ]

    If you're working in the Oracle world, then you're probably familiar with the spaghetti mess that any significant PL-SQL application becomes. Programming in stored procedures for the majority of your codebase tends to lead to hard-to-track errors and a confusing codebase, unless your team is EXTREMELY organized. Also, such an application tends to be a bit further abstracted from the business problem that it tries to solve. Object oriented languages have a tendency to "read" a bit closer to the business problem, because you end up modeling constructs that match your business problem ("order", "Customer", etc.). While you do a similar modeling in a purely db driven application by modeling things as tables, when you interact with the tables you are dealing with the idiosyncracies of SQL, which is primarily a set-based language. Vendor-specific mechanisms such as PLSQL or TransactSQL try to patch a layer of programmability beyond ANSI SQL on top of this, but it's a graft job and it shows.

    So my main argument against putting business logic in vendor-specific database code is that the result is far less maintainable and far more costly to develop than equivalent code in Java or .NET code. I also happen to know that PL-SQL developers are a bit more costly than Java or .NET developers, at least in the bay area. That's primarily because of the complexity of PL-SQL, but is now becoming even more true because they're more of a rare breed now, and their primary clients are organizations stuck dealing with a legacy codebase in PLSQL.

    Also, look at maintainability as something you can calculate based on the number of code artifacts. For database persistence using Hibernate, I need a table, a class, and a mapping file. This will handle all CRUD operations as well as queries. If I keep the table, the Java class, and try to do the rest using the database, I end up with four more stored procedures, one for each CRUD operation. I also end up with a query procedure, or potentially more than one in case you wanted to have a separate one for each type of query. That's taken 3 code objects and multiplied it into 8. That's almost a 3X increase in the number of objects in my system, which kills my maintainability simply because there's so much more to maintain. Imagine that in a system with 20 or so common business objects, and the problem explodes. Imagine further a situation where 10 of the 20 get a whole new set of fields and relationships due to change requests. Which setup do you think will have an easier time with that change?

    I don't think that vendor-specific features are necessarily evil, it's just that I think they have historically been overused. If there's an easier way to do something that leads to more maintainable code and lower overall cost then I'll use it. If I have no other choice than to use a vendor-specific feature, then I'll use it. But I think that most vendor-specific features are completely unnecessary for the vast majority of business applications out there.
  90. Thin ice[ Go to top ]

    Programming in stored procedures for the majority of your codebase tends to lead to hard-to-track errors and a confusing codebase, unless your team is EXTREMELY organized.
    In our experience this is exactly the case, customers being EXTREMELY organized that is. That's the reason why they want to keep their investments in stored database code secured, because they know it works and works fast.
    So my main argument against putting business logic in vendor-specific database code is that the result is far less maintainable and far more costly to develop than equivalent code in Java or .NET code.
    Hey, they can even switch from Oracle*Forms, Java/J2EE, C#/Net, or whatever language/platform will be next without rewriting everything.
  91. Thin ice[ Go to top ]

    Programming in stored procedures for the majority of your codebase tends to lead to hard-to-track errors and a confusing codebase, unless your team is EXTREMELY organized.
    In our experience this is exactly the case, customers being EXTREMELY organized that is. That's the reason why they want to keep their investments in stored database code secured, because they know it works and works fast.
    So my main argument against putting business logic in vendor-specific database code is that the result is far less maintainable and far more costly to develop than equivalent code in Java or .NET code.
    Hey, they can even switch from Oracle*Forms, Java/J2EE, C#/Net, or whatever language/platform will be next without rewriting everything.
    That hasn't been my experience. I have been part of projects where we had to rewrite systems because of code ie business logic that was in stored procedures.

    It is fast. It is easy to hack out. It is a bear to modifiy and maintain. "How come the first guy did this in a two months, but you need four to change it?" Because it is extremely hostile to change.

    I worked for a place as a consultant that want business logic, in java, in stored procedures in DB2. I refused flat out. "If you want to let me go, that is your choice.", I said, but I would not be party to something I *knew* would come back and haunt them.

    There always a choice. I wouldn't take a job that had the application designed dictated to me by DBAs because the DBAs won't be there at 60hrs a week trying to code around their "design" decisions.
  92. Thin ice[ Go to top ]

    That's the reason why they want to keep their investments in stored database code secured, because they know it works and works fast.
    Are you sure it's really faster ? Have a look at this http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
  93. Thin ice[ Go to top ]

    For Oracle stored procedures, that have been written by people who know what they're doing, they are really fast. I don't know how SQLServer compares to them however. But my initial point was about using everything 'good' the underlying database has to offer. In most of our projects this is Oracle.
  94. Thank you for placing a link to what seems IMO to be the last reasonable man in the Universe.

    (http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx)

    Frans Bouma:
    The alternative to O/R does not have to be Stored procedures. It is Dynamic SQL generated based on objects written in Java or C#.

    Precisly
    A good Dynamic SQL engine creates parametrized queries, which are not only faster (because the execution plan is cached), they are also not open for SQL injection attacks due to the parameters.

    Precisly
    I too find writing code like string s = "SELECT * FROM Foo WHERE Bar = " + barValue; in your code not the right thing to do. However the alternative is not stored procedures, it's a component that generates this SQL on the fly..

    Precisly

    You have two levels of data-access which is independent of the database schema. The level most close to the database is removable, to be changed for another database, The other level (100% generic) that never changes, builds the AD-hoc SQL queries. + Table/field-mapping.

    And before anyone say that this is "a homegrown framework" I will definitely deny that 150 -200 lines of code constitutes a framework, homegrown or not. Just ordinare snippets of code, part of the baggage that belongs to all experienced developers. And you can change the database very easily but still have the full power of (Joe Celko) SQL.

    Regards
    Rolf Tollerud
  95. This is my toy http://voruta.sourceforge.net, it is very simple ( I know nothing more simple than SQL ) but it is very powerfull tool for the data access. I have no time for "profesional" marketing, but I hope it can inspire more usefull discussion than "object" guys vs. "database" guys.
  96. Thank you for placing a link to what seems IMO to be the last reasonable man in the Universe.(http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx)Frans Bouma:
    Yeah,was good to read. But does compiling/pre-compiling sql is _the_most_important
    reason which affects performance?
    To my observation,the way data is accessed(the way tables are joined in SQL) is almost always the culprit for poor performance.
  97. Um, at what point did what you're talking about become a better alternative to something like Hibernate? You're talking about 250 lines of code that generate SQL. Somewhere along the line you maybe forgot that that's pretty much exactly what Hibernate is doing. And I would be willing to bet that it's generating better SQL, and for more situations and uses. I just don't get how Hibernate has become this cumbersome monolith to some people. It's not. It's not the be-all-end-all, but for most situations, including most likely the one you're talking about, it fits just right.
  98. Drew,

    Respectfully I must say that you have misunderstood. With Dynamic SQL a la Frans Bouma (which is more or less what I endorse) it is you that writes the SQL. Hibernate generate its own SQL. That is a big difference. As the difference in lines of code and performance.

    The component that generates SQL on the fly only make the humdrum of setting up the parameterized query a little easier and also gives some extra opportunities that has to do with role-based security. (You can add system-wide last-minute restrictions to the SQl-command).

    In return you get an Hashmap, simple Arraylist or Dataset. Whatever. I mostly prefer a simple Arraylist.

    Regards
    Rolf Tollerud
  99. Dynamic SQL![ Go to top ]

    With Dynamic SQL a la Frans Bouma (which is more or less what I endorse) it is you that writes the SQL.
    You mean I get to write the SQL. This is what I want to avoid unless I have to. Writing SQL by hand is mundane and error prone.
    In return you get an Hashmap, simple Arraylist or Dataset. Whatever. I mostly prefer a simple Arraylist.
    So then I have to map the returned values back to my objects? Again, no thanks. How do associations work? Do I have to write any outer-join queries myself. If so, a big double not thanks to that.

    Ryan
  100. I love SQL[ Go to top ]

    "Writing SQL by hand is mundane and error prone"

    Nonetheless, that is what i prefer. I also enjoy reading Joe Celko. Never ever am I to throw away that knowledge.

    Regards
    Rolf Tollerud
    (never ever)
  101. I love SQL[ Go to top ]

    "Writing SQL by hand is mundane and error prone"Nonetheless, that is what i prefer. I also enjoy reading Joe Celko. Never ever am I to throw away that knowledge.RegardsRolf Tollerud(never ever)
    Quoth the Raven, "Nevermore!" ;)
  102. Dynamic SQL![ Go to top ]

    So then I have to map the returned values back to my objects? Again, no thanks. How do associations work? Do I have to write any outer-join queries myself. If so, a big double not thanks to that.Ryan
    Yes, it is a nonsence to to map the returned values back to objects manualy, it is
    too trivial and doe's not depend on domain, any tool can do trivial type mappings without matadata, but simple tool can not map ralationships without additional metadata, mapping helps for CRUD too. There are a lot of use cases for both ways, differnce is very trivial if you write data access code manualy, but difference is very big if you generate this code from UML models. I am not MDA fan, but this is the right way if you prefer "complex object graph", I saw how it works in practice.
  103. Thin ice[ Go to top ]

    Well said Drew. I'm glad I waited and didn't try to post the same thing. I wouldn't have said it as well.
  104. CRUD as stored procedure?[ Go to top ]

    Object oriented languages have a tendency to "read" a bit closer to the business problem, because you end up modeling constructs that match your business problem ("order", "Customer", etc.). While you do a similar modeling in a purely db driven application by modeling things as tables, when you interact with the tables you are dealing with the idiosyncracies of SQL, which is primarily a set-based language.
    Imho the whole point to use relational algebra (and SQL being the language of this algebra) is the ability to work with a set of data in the same manner as with one data item.
    For database persistence using Hibernate, I need a table, a class, and a mapping file. This will handle all CRUD operations as well as queries. If I keep the table, the Java class, and try to do the rest using the database, I end up with four more stored procedures, one for each CRUD operation. I also end up with a query procedure, or potentially more than one in case you wanted to have a separate one for each type of query. That's taken 3 code objects and multiplied it into 8.
    This is exaggeration. Data operations which work with single items (objects) don't have to be programmed as stored procedures, a simple INSERT or UPDATE statement would suffice. And it is efficient too, the server would apply the index automatically or you can generate an index manually. Clustered index would be blazing fast. Such query is pretty efficient even in its dynamic form, without preparing it. I personally don't know anyone who is that big a freak to create a stored procedure for EACH AND EVERY database access/update.

    ORM is great for single item operations, while the real benefit of stored procedures is set operations. SQL servers went through 20 years of evolution, and they can do set operations much faster using stored procedures. And do not forget about network load.
  105. CRUD as stored procedure?[ Go to top ]

    ORM is great for single item operations, while the real benefit of stored procedures is set operations. SQL servers went through 20 years of evolution, and they can do set operations much faster using stored procedures.
    With this, I'll definitely agree. None of our massive nightly batch process use ORM DAOs.
  106. CRUD as stored procedure?[ Go to top ]

    ORM is great for single item operations, while the real benefit of stored procedures is set operations. SQL servers went through 20 years of evolution, and they can do set operations much faster using stored procedures.
    With this, I'll definitely agree. None of our massive nightly batch process use ORM DAOs.
    Ahhh. The data shuffle. or the data Hokey Pokey.
  107. CRUD as stored procedure?[ Go to top ]

    ORM is great for single item operations, while the real benefit of stored procedures is set operations. SQL servers went through 20 years of evolution, and they can do set operations much faster using stored procedures.
    With this, I'll definitely agree. None of our massive nightly batch process use ORM DAOs.
    I guess I should try to port Hibernate to COBOL then. :)
  108. CRUD as stored procedure?[ Go to top ]

    shouldn't
  109. Re: Thin Ice[ Go to top ]

    With the risk of not being taken seriously by the 'J2EE world' I feel the need to ask the following question.Why aren't we using the power/performance and functionality the underlying database is providing us?
    That is fair to say. I've done projects in the passed where I had to bind all of my java code using hand written sql and it was a tedious effort to code and maintain.

    The next point re: the use of stored procs is very interesting. The current project I am working has legacy MS C++ using stored proces. We use Hibernate on the Java side and the amount of effort between the J2ee team and the legacy team, expended on the query level is not even comparable. Also the DBAs/DBEs become bottlenecks on large projects when plsql has to be written or debugged.

    If a table has a new column added I run two ant tasks that regen the Hibernate mapping files and Java DTOs (beans). The DAO classes are templates generated witihin our IDE so I don't have to touch them unless the new field(s) are used in a finder method (query).

    No then as to the poor souls maintaining the plsql... They have to change all of their plsql that does insert/update and select and also modify their code that interfaces with the argument list of these affected plsql statements.

    ONE THE LIGHT BULB GOES OFF YOU WILL NEVER LOOK BACK TO USING ANYTHING OTHER THAN AN ORM MAPPING TOOL LIKE HIBERNATE.

    Best Regards,

    Cory Adams
  110. Re: Thin Ice[ Go to top ]

    Also the DBAs/DBEs become bottlenecks on large projects when plsql has to be written or debugged.If a table has a new column added I run two ant tasks that regen the Hibernate mapping files and Java DTOs (beans).
    Model is usefull for modeling only (for people without math background), code generation is a transformation from model to code (abstraction).
    If you generate code then you do not need to know about any runtime mapping aka ORM or stored procedures, you never maintain generated code, do you ?
    Change transformation and you will get stored procedures,COBOL or C++. But I think it is better to abstract domain model than abstraction itself (the same code and machine can contribute for many domains at the same time).
  111. Just FYI,

    Daffodil DB is a Java database engine that is fully compliant with Hibernate, as also JBoss. Have a look at www.daffodildb.com

    Cheers,
    Uday
  112. Sometimes I prefer

    statement.executeQuery("select * from table where id="+id)

    over

    connection.perepareStatement("select * from table where id = ?")

    There are cases where dynamic SQL performs match better!
    For instance on Oracle:

    statement.executeQuery("select * from table where name like 'John%'")

    will use index on column "name", but

    connection.perepareStatement("select * from table where name like ?")

    will never use index on column "name".

    I expect a framework to support both styles of parameter substitution.

    When I say something like:

    frameworkMethod("select * from table where colum=?",
     new Object[]{param}, dynamic)

    It should build dynamic sql with proper character escaping and date format or use prepared statement depending on boolean parameter "dynamic".

    Does Hibernate or iBATIS support or plan to support something like that?

    Nebojsa
  113. The comments so far seem to be:
    1.The ability to change databases is vital.
    2.Custom SQL for complex cross table joins is vital.
    3.An optimised relational database which can be used for many technologies is vital.

    The arguments then become more about your perspective:
    - do you sell to multiple vendors, in which case having all sql in java is great, and better yet hibernate does runtime sql generation using dialects. Hibernate also support (2) via custom sql (hand written). However, it's not clear how such custom sql for (2) would port - so use hubernate for CRUS, and something else for (2).
    - are you a large enterprise system, never to change the database, but likely to use many technologies on top of the same database. In which case stored procedures may have a role in embedding business logic at the root of the system.
    - persistance of relational object graphs is paramount/irrelevant. This is religious - I've seen it kill multi million pound projects. Others have seen it do great stuff.

    Solutions proposed:
    Hibernate/Ibatis
    Ibatis/Stored procs
    JDBS/Stored procs

    My Solution:
    DAO - a simple, compile time technology which supports all of the above. There are lots of way to autogenerate for CRUD - over multi DB's. Then you custom code cross table ops in target specific implementations of a base class.

    No runtime component means it's very maintainable - a glance at the code shows you what is going on. You can optimise sql in java, move to sprocs as you want and your persistence layer is decoupled from the business logic. You do NOT have any in-line sql within your main code base.

    Am I biased? Yes. I believe in this so much I invested time in a code generation tool. Not only that, I deprecated my EJB code generator (the lowroad) because EJB is finally, thankfully dead. Emeraldjb may not currently support every DB, but this will come with demand. It does support auto archiving, optimistic locking, native or custom pkeys, multi-column pkeys and so on.

    DAO is the SIMPLEST way of doing O/R. It's agile (do what you need for now) and fit for purpose (supports what you need now and in the future). It's transparent (you can see all the behaviour in the source code) and maintainable (you can see ALL of the behaviour in the source code).

    Jonathan
    Emeraldjb - DAO generation for every architecture.
  114. SQL Compiler[ Go to top ]

    What I use to work with databases is SQL Compiler. I find it pretty useful, but my opinion is biased :-)
    Give it a try.
  115. integrate with the database[ Go to top ]

    Hi Jan,

    Certainly, databases are long-standing and critical to most company's business systems. Companies care more about their data and ongoing business, than changing to meet the latest technology.

    Because of the importance of existing data, we feel it's better to map databases. This allows integration for existing projects but also gives flexibility to change infrastructure in future. Our JDO product focuses on this requirement in particular.

    Granted, you can transition direct SQL better than stored procedures. However with modular coding and planning in the application, even major changes can be kept clean.


    Regards,
    Thomas Whitmore
    www.powermapjdo.com