SavePoint – A Lightweight Persistence Engine – released

Discussions

News: SavePoint – A Lightweight Persistence Engine – released

  1. We are pleased to announce the first release of SavePoint. SavePoint is a lightweight Java persistence engine, designed to meet the most difficult and complex needs of the enterprise application, especially where existing frameworks, such as Hibernate and iBATIS, fall short. SavePoint is conceptually simple. It does not require any explicit object relational mappings. Instead, it embeds the mapping information directly into SQL statements hosted in XML files that contain persistence instructions. The persistence instruction controls how the SQL statements are executed. The main benefits of SavePoint include:
    • It helps you build a simple, flexible, highly maintainable and high-performance persistence architecture. SavePoint lets you to work directly with structured domain objects and to potentially eliminate the redundant data access objects from your application architecture.
    • It gives you complete control over the SQL. It fully preserves the power, flexibility and efficiency of the advanced native SQL you need to meet the most complex and difficult business requirements. It automatically transforms the result sets returned by your query into structured return objects, including complex object graphs and objects of recursive structure.
    • It provides a straightforward method for you to handle variable or dynamic SQL. It lets you to mark any parts of a pre-prepared SQL statement to be variable or optional, in contrast to conventionally building up the SQL string by conditionally adding up SQL fragments through awkward Java API or verbose XML tags.
    • Even in this first release, SavePoint is packed with features needed to support the persistence needs of a serious enterprise application.
    Most interaction takes place within a Session object, which provides CRUD methods as well as access to a more sophisticated Query API. The Session object uses operations defined in an XML configuration to execute SQL statements in order, and with an object mapping syntax to refer to parameter data. There's also a named query facility, with queries being able to map to object data or use an equivalent to the PreparedStatement's parameter mutators. What do you think of the project? Message was edited by: joeo@enigmastation.com

    Threaded Messages (57)

  2. What do I think[ Go to top ]

    What do you think of the project?
    Dunno, I stopped reading after "it embeds the mapping information directly into SQL statements hosted in XML files"
  3. Re: What do I think[ Go to top ]

    What do you think of the project?

    Dunno, I stopped reading after "it embeds the mapping information directly into SQL statements hosted in XML files"
    I admit I stopped at the same point. I did however click their link to look around the site. Once I came across this page, http://savepoint.ytzsys.com/?page_id=30, I got out of there. I've used hibernate for a few years, and one of the things I like about it is that I don't have to write this kind of SQL every time I need to persist something.
  4. Re: What do I think[ Go to top ]

    What do you think of the project?

    Dunno, I stopped reading after "it embeds the mapping information directly into SQL statements hosted in XML files"



    I admit I stopped at the same point. I did however click their link to look around the site.

    Once I came across this page, http://savepoint.ytzsys.com/?page_id=30, I got out of there. I've used hibernate for a few years, and one of the things I like about it is that I don't have to write this kind of SQL every time I need to persist something.
    Yeah, and this is supposed to help when Hibernate "falls short". Kind of makes me wonder how much they know about Hibernate...
  5. Re: What do I think[ Go to top ]

    I admit I stopped at the same point. I did however click their link to look around the site.

    Once I came across this page, http://savepoint.ytzsys.com/?page_id=30, I got out of there. I've used hibernate for a few years, and one of the things I like about it is that I don't have to write this kind of SQL every time I need to persist something.
    Bufff... that XML was nasty! Is the author really serious he prefers that to Hibernate?
  6. Re: What do I think[ Go to top ]

    Bufff... that XML was nasty! Is the author really serious he prefers that to Hibernate?
    And this for a simple class...
  7. Re: What do I think[ Go to top ]

    I'd feel embarrassed if this was my project
  8. I agree with Steve[ Go to top ]

    What do you think of the project?

    Dunno, I stopped reading after "it embeds the mapping information directly into SQL statements hosted in XML files"
    Same here.. That is the point when I started looking at comments. If there is a new java persistance project trying to replace Hibernate, it probably has to do something very un-intrusive. It should probably implement JPA in a lightweight fashion without giving the advanced functionality, almost like a stepping stone to go to TopLink or Hibernate, if needed. I feel that we have enough JPA implementations actually, and we really need tools that make adopting JPA easier. For example, Eclipse Dali (http://www.eclipse.org/webtools/dali/main.php). If SavePoint does work well for the author however, then Congratulations! These things are certainly not piece of cake to implement. my few cents, Paul Dhaliwal
  9. It is no Silver Bullet...[ Go to top ]

    ...but I think the effort should be appreciated even if the tool does not fit in our current or future development projects/preferences. Complexity in software development comes in countless shapes and I, for one, like to have at hand as many options/tools as possible to deal with it. Don't you agree?
  10. ...but I think the effort should be appreciated even if the tool does not fit in our current or future development projects/preferences.
    SQL in XML is a terrible idea and always will be. Why should misguided commercial software in anyway deserve appreciation?
    Complexity in software development comes in countless shapes and I, for one, like to have at hand as many options/tools as possible to deal with it.

    Don't you agree?
    Definitely not. This tool is not fit for purpose by design. But feel free to fill your toolbox with as many broken frameworks as you like.
    It is no Silver Bullet...
    If only I had a penny for every time someone churned this old chestnut out.
  11. SQL in XML is a terrible idea and always will be.
    It's not always. Years ago, I created (for our own internal usage) a query manager system that also stored SQL in XML files along with some meta data. In my case the XML was just an internal storage format, which was rendered by an editor to show the SQL in one pane and the meta data fields as a kind of form below it. So basically all that the user saw in his editor was something like: select * from table where table.column = @someVar In code you could execute this, by doing something like: queryManager.load("queryName"); queryManager.setParam( "someVar", 5); queryManager.execute(); Later Hibernate came along and we adopted that, too. But for simple data queries, where we don't have to deal with an object-graph but just have a table of 'data', we're still using this (in house) system.
  12. Appreciation issues[ Go to top ]

    Hi Steve! Thanks for taking time to comment. Just to clarify: I'm not asking to throw everything in the bag *just in case*, I'm only saying that if what SavePoint (or any other persistence framework, for that matter) offers does not fit in our development world that does not give us reasons/excuses to diminish the effort. In discussions like this I try to keep in mind a very simple principle: If you don't like, don't use it. If you don't like the way it is, improve it. Oh, and I'm sorry about the old chestnut reference (it is hard to forget the classics), please replace every occurrence with anything that expresses the same idea ;^) Have a good day.
  13. NIH Pattern[ Go to top ]

    This here attaympt at creatin uh persistunce framewerk iz just an implimentation of ye ole' Not Invented Here pattern. A.K.A. - "I gotta make one too!" pattern. The benefits of SavePoint shud prolly be adjusted tuh read: "If you'uns like to micro-manage boring SQL statements and mappings, yall izz gonna luv usin this here framework." Them waskalz!
  14. When I stopped reading...[ Go to top ]

    I got as far as: "Savepoint is not an open-source project" Should I trust such a critical piece of the project to something I can't even get at the guts of? Not so much. *sigh*
  15. Is open source that critical?[ Go to top ]

    I got as far as:

    "Savepoint is not an open-source project"

    Should I trust such a critical piece of the project to something I can't even get at the guts of? Not so much.

    *sigh*
    I am surprised to find that you evaluate a product only based on one factor: open source. Maybe this is just a personal preference. I don't think open-source is a point of argument here. There are many "closed" source softwares that people use. Java wasn't open-sourced until 10 years later. C# is not open source. Oracle is not open source. M$ Office is not open source. The list can go very long. There are many factors to conside when making a serious choice of software: technical qualities, financial budgets, enterprise integrations, etc. Being open source or not is just one of the factors.
  16. the SavePoint site sayz: "Powered by Wordpress" and the forum is created using phpBB. Now why cain't somebody spendz thar time uh creatin the Java-equivalent of such popular (php-based) programs as Wordpress and phpBB? Izzuh thinkin we gots Java persistence solved mighty dang well with many parmutationz tuh play around with. Weez alsuh makin good progress on UI with JSF component libraries. It's just a might bit bafflin that no one's a focusin on uh makin web-community-creatin tools like these - insteadz, we J2EE/JEE fanboyz gots uh new persistence framewerk and a new web framewerk every few dayz er so. Immuh tellin yall it jus ain't right that folkz izz uh solvin thuh same problems over and over - it ain't!
  17. Hey there is Roller for competing against WordPress. But, yes, we do need a killer equivalent to PhpBB and your point is very valid. To the author of SavePoint: Don't be depressed by the critical feedback you've received. Instead, learn from it and become wiser for next time. You've been able to take an idea to completion and build everything around it to make it presentable. But the core content was not worth the effort. So take the experience and go create something new and innovative.
  18. But, yes, we do need a killer equivalent to PhpBB
    MvnForum is JSP/servlet based
  19. Er yes, but....[ Go to top ]

    But, yes, we do need a killer equivalent to PhpBB

    MvnForum is JSP/servlet based
    Last time I peeked at mvn, the code was very 'sphagetti'ish'... I cain't really regard that thar mvnforum as a 'killer equivalent to PhpBB'. I reckonz one of the points tuh usin Java under thuh hood is tuh get a reasonable design in thuh code. I ain't really looked at roller but Pebble looks cleaner/better on first pass, also, somethin with the flexibility of Facelets + JSF for the UI would be ideal.
  20. JForum for phpBB Fans[ Go to top ]

    Java equivalent to phpBB? Try JForum http://jforum.net/ Pretty go stuff. I believe the reason one would go with Wordpress and phpBB is generally because php hosting is cheaper and easier to come by. They, both phpBB and WordPress, are also pretty respectable projects.
  21. Jive Forums / Clearspace[ Go to top ]

    If you are looking for quality community collaboration tools like WordPress and phpBB written completely in Java, take a look at Jive Software's Clearspace and Forums applications. Unfortunately they are not free, but they do donate free licenses to open source projects.
  22. Brutal[ Go to top ]

    - Not open source - ugly XML - lacks simplicity/low config of better ORMs And by the way, WTF does lightweight mean in this case? Compared to what? That word means nothing anymore. Okay, the problem with this is the XML. You're using XML to program, a classic horrible mistake. It DOES look like there is some nice logic/utilities/classes for doing ORM for those people that like SQL. Ditch the XML somehow. CDATAs? Seriously?
  23. This looks like one serious case of Not Invented Here Syndrome. Why do people bother building these frameworks? There is nothing innovative to find and it certainly is not lightweight in development time terms. S.
  24. 2004?[ Go to top ]

    The online user guide shows "April 2004", see: http://savepoint.ytzsys.com/docs/UserGuide.htm Why does the post start with: "We are pleased to announce the first release of SavePoint"?
  25. is this a joke?[ Go to top ]

    such as Hibernate [...], fall short.
    Ummm..such as where? Is this a joke, really? WTF would someone bother building persistence engines with the gazillion free versions already available????????????????????????
  26. I don't know why iBatis will "fall short" from what I've seen I don't think it is that much different in terms of defining the SQL, I would prefer IBatis style though. Anyway ... CDATA ?
  27. I don't know why iBatis will "fall short" from what I've seen I don't think it is that much different in terms of defining the SQL, I would prefer IBatis style though. Anyway ... CDATA ?
    1. iBATIS is nice when the persistence object is simple. It is with complex objects, iBATIS does not work that nice. Is it possible to populate a complex object graph, see a customer object with a collection of shipping addresses and a collection of billing addresses, with one single query? It is an easy job to use iBATIS to populate a recursive object structure? 2. The CDATA is used to keep the SQL in a readily testable format. A feature of SavePoint is that you may simply copy any SQL in the persistence instruction and paste it into a SQL editor, such as TOAD, and you can test it and run explain-plan on it without needing to modify it. This is true even for dynamic SQL. CDATA and other design details are adopted for this purpose.
  28. A Clarification[ Go to top ]

    Thanks for all your comments, although some of them ARE brutal. Clearly, SavePoint is not for every body, and especially it is not for those who prefer to stay away from SQL. However, it is hard to imagine that you could avoid SQL completely when dealing with relational database, especially in the context of enterprise applications. After all, it is the language the relational database speaks. If SavePoint is not for every body, then who is it for? I would say it is for those who believes • SQL, and all persistence details for that matter, should be externalized; • Developer, rather than the persistence framework, should have the ultimate control of the SQL; • Writing SQL is easier than writing HSQL or QL; • The persistence framework should be least intruding. It should not dictate or impact how the data and object models should be designed; and • Given Hibernate, iBATIS and JDBC, he would choose iBATIS or even JDBC. In this aspect, SavePoint is similar to iBATIS, but it has several important improvements, including • It combines the SQL statement with the result mapping; • It completely avoids the N+1 problem, even in the case of deep and wide persistence objects; • It provides a simpler way (in our opinion) to handle dynamic SQL; Plus it supports or plan to support recursive structure, blob and clob, inheritance and polymorphism, connect-by query, object type and other features that are useful to enterprise applications. It would be naïve to think that everybody is satisfied with Hibernate. Otherwise, there would be no people who pick iBATIS vs Hibernate, and no developers who revert back from Hibernate to JDBC when dealing with complex queries. Enterprise application is too complicated; O-R mapping is simply not flexible enough to cover all the needs. That is why even Hibernate states that it does not want to hide the power of SQL from the user. In the space of relational database, SQL is the king, not Hibernate. We propose SavePoint as a lightweight persistence engine, because • First, it is light in concepts: persistence engine, persistence session, query, plus persistence instruction. That is almost all we got. Simple and intuitive. • Second, it adds little on top of JDBC, it passes through the SQL, and transforms the SQL result set into structured objects. It does only what a JBDC developer would hope the engine to do, no more. We are positioning SavePoint as a persistence engine for enterprise, because that is where we believe the strength of SavePoint is. It stays simple as things (query and objects) become complex, whereas Hibernate and iBATIS would stop being simple in such case. If you have doubt about this point, we challenge you to submit your complex query problems to our user forum, we will give you our solution for you to compare with your solution using Hibernate or iBATIS. SavePoint is not an open source project (why every project has to be open source?). However, it does let you to use it for free if you are using a free or open source database. This is to help startups or projects with limited financial resources. This is also a way to give back to the community. If you use it with a commercial database, we plan to collect a nominal fee comparable to the annual support of Hibernate, in future. SavePoint is targeted at enterprises. If it provides value to the enterprise, why can’t we share a tiny fraction of this benefit? SavePoint is indeed not for everybody. It is for people who are seriously searching and evaluating solutions for their current or future persistence needs, especially in the context of enterprise applications. If you are such people, you are cordially invited to check the list of features implemented and to be implemented in SavePoint the list of examples how SavePoint could be used in various scenarios the PDF version of User Guide (not the draft, unpublished HTML version), and; the tutorial demonstrating how to use SavePoint in your application through re-implementing the persistence layer of the iBATIS JPetStore with SavePoint. The product may be downloaded here with User Guide. Ken Wang
  29. No thanks[ Go to top ]

    "Clearly, SavePoint is not for every body, and especially it is not for those who prefer to stay away from SQL" Hibernate doesn't force you to stay away from SQL. You can have both. Now, the only hazzle with Hibernate was the mapping files, but we even got rid of those by generating them from the domain model. "Writing SQL is easier than writing HSQL or QL; " I beg to differ. HQL allows me to write in the language of the domain model (which is *especially* important in our large enterprise apps). And I can always drop back to SQL if I need to (which is basically never with Hib 3.x). "..., and no developers who revert back from Hibernate to JDBC when dealing with complex queries" Hibernate allowing both models is usually considered a strength. I seriously doubt you have learned Hibernate properly. "The product may be downloaded here with User Guide." No thanks.
  30. Re: No thanks[ Go to top ]

    "I beg to differ. HQL allows me to write in the language of the domain model (which is *especially* important in our large enterprise apps). And I can always drop back to SQL if I need to (which is basically never with Hib 3.x).


    Show me the most complex query you have written in HSQL or native SQL. Show me the most complex query in your enterprise application. I really like to see it. Do you consider maintenance, performace etc., when you generate the mappings, and probably the DB tables, using the tools? Are you able to test your query at development time when you use the Criteria API to build up your SQL at runtime? Does your DBA like all these ideas? And who says SavePoint is not object-oriented? It is specically designed to work with Domain Objects, only it allows you to see and control the details in the persistence instruction, which, by the way, also servers as a formal contract between the application and the persistence engine. With SavePoint, you can load a complicated domain object with one single query. To do the same, how many queries do you think Hibernate normally fires? Hundreds. These query are hidden anyway...wait, may be not, when you chose lay loading. In that case, you have to whip it for it to move. What about the N+1 problem? Not a potential performance issue? All depending on how big and complex you object is. Maybe you know a better way to use Hibernate. I am not a Hibernate expert anyway. And how many efforts it takes to become one?
  31. Re: No thanks[ Go to top ]

    "I beg to differ. HQL allows me to write in the language of the domain model (which is *especially* important in our large enterprise apps). And I can always drop back to SQL if I need to (which is basically never with Hib 3.x).




    Show me the most complex query you have written in HSQL or native SQL. Show me the most complex query in your enterprise application. I really like to see it.
    No, I can't post closed source code here, and I don't see why I should have to anyway. I have written fairly hairy SQL's in my days. If you don't believe that, then that's your problem and you should go away. These queries tend to get simpler when using HQL.
    Do you consider maintenance, performace etc., when you generate the mappings, and probably the DB tables, using the tools?
    Yes, the tool generates from a domain model and optimizes the mapping generation (this is an in-hous tool).
    Are you able to test your query at development time when you use the Criteria API to build up your SQL at runtime?
    Yes... there are tools for that.
    Does your DBA like all these ideas?
    I'm the DBA (there are others). If you are one of those that believe there is *THE* DBA these days, then you need to wake up and smell the new century.
    And who says SavePoint is not object-oriented? It is specically designed to work with Domain Objects
    I don't care because mixing mapping and sql is terminally stupid.
    What about the N+1 problem? Not a potential performance issue? All depending on how big and complex you object is.

    Maybe you know a better way to use Hibernate. I am not a Hibernate expert anyway.
    There is a FAQ about this, and in Hib3 I use fetch="subselect". There is also the lazy option (our tool generates the correct laziness for collections, proxies, etc) So N+1 is NOT a problem in Hibernate. Stop the FUD.
    And how many efforts it takes to become one?
    Only one effort required.
  32. Re: No thanks[ Go to top ]

    Show me the most complex query you have written in HSQL or native SQL. Show me the most complex query in your enterprise application. I really like to see it.
    Ken, I would like to add that I think you have a lot of nerves implying that Hibernate is unsuitable for large and complex enterprise systems, and that somehow falling back to SQL is a prequisite for anything non-trivial. A lot of the (fair) negative feedback you have received is due to the way you try to "sell" the technology. We could give you all sorts off references, testimonials and anecdotal evidence about how Hibernate is used in replicated (using Shards), mission critical Telco and Health care systems, but I don't have to. Just google around and see for yourself. I'm not affiliated with the Hibernate project, nor JBoss, but your bashing based on a profound lack of insight into the product is really annoying. The next time you want to sell something to a technical crew, don't start by saying the tool they use as a daily saviour "falls short". That's just bad salemanship...
  33. Re: No thanks[ Go to top ]

    Ken, I would like to add that I think you have a lot of nerves implying that Hibernate was unsuitable for large and complex enterprise systems, and that somehow falling back to SQL is a prequisite for anything non-trivial. A lot of the (fair) negative feedback you have received is due to the way you try to "sell" the technology.
    Do you think Hibernate is an improvement over EJB before 3.0? Do you think that EJB is unsuitable for large and complex enterprise systems? You'v got believe that things can be be done differently and that people have difference preferences. You think Hibernate is perfect and there are a lot people with you. I think Hibernate is not good enough and I am piching to people would agree with me. If I don't see the shortcomings of Hibernate in complex enterprise applications. Why I want to take time to do SavePoint? Whether people agree with me or not, that is another problem. Hibernate is a good product. I am totally with you. It is the best of all ORM offerings (hope not affending TOPLink people). It gives you a sense of quality. It is embraced by a lot developers, like you. However, it is an ORM soltuion, and ORM solution has limitations, although the limitation may not be as bad as the Vietnam of Computer Science as Ted Neward has put it. The first softspot of Hibernate, as I see, is the query, the complex query in enterprise settings. Do you see the post by Joel Schilling. For a not-that-complex query, you need to create a view. Does the view need to be maintained? Do I need a view for each not-that-simple query I need to do? How do I control the performance of the view? The database will automatically takes of care of that. Do you see it always happens from your own DBA experience? The second softspot of Hibernate is the steep learning curve. Is there anyone who says Hibernate is easier to learn than iBATIS? Do you know there are demands for Hibernate experties and Hibernate consultants? Anything that requires experties and expert consultants, to me, that is a sign that the stuff is not simple. Period. However, Java persistence should not be that complicated, there must be a simple or simpler solution. That is what SavePoint tries to find. That is also how Hibernate became Hibernate, I believe. Of course, the above are all my personal opinions. I respect you rights to not agree with me. Thanks for your comments.
  34. Re: No thanks[ Go to top ]

    Ken, I would like to add that I think you have a lot of nerves implying that Hibernate was unsuitable for large and complex enterprise systems, and that somehow falling back to SQL is a prequisite for anything non-trivial. A lot of the (fair) negative feedback you have received is due to the way you try to "sell" the technology.


    Do you think Hibernate is an improvement over EJB before 3.0? Do you think that EJB is unsuitable for large and complex enterprise systems? You'v got believe that things can be be done differently and that people have difference preferences.

    You think Hibernate is perfect and there are a lot people with you. I think Hibernate is not good enough and I am piching to people would agree with me. If I don't see the shortcomings of Hibernate in complex enterprise applications. Why I want to take time to do SavePoint? Whether people agree with me or not, that is another problem.

    Hibernate is a good product. I am totally with you. It is the best of all ORM offerings (hope not affending TOPLink people). It gives you a sense of quality. It is embraced by a lot developers, like you. However, it is an ORM soltuion, and ORM solution has limitations, although the limitation may not be as bad as the Vietnam of Computer Science as Ted Neward has put it.

    The first softspot of Hibernate, as I see, is the query, the complex query in enterprise settings. Do you see the post by Joel Schilling. For a not-that-complex query, you need to create a view. Does the view need to be maintained? Do I need a view for each not-that-simple query I need to do? How do I control the performance of the view? The database will automatically takes of care of that. Do you see it always happens from your own DBA experience?

    The second softspot of Hibernate is the steep learning curve. Is there anyone who says Hibernate is easier to learn than iBATIS? Do you know there are demands for Hibernate experties and Hibernate consultants? Anything that requires experties and expert consultants, to me, that is a sign that the stuff is not simple. Period.

    However, Java persistence should not be that complicated, there must be a simple or simpler solution. That is what SavePoint tries to find. That is also how Hibernate became Hibernate, I believe.

    Of course, the above are all my personal opinions. I respect you rights to not agree with me.

    Thanks for your comments.
    I simply don't agree that Hibernate has a steep learning curve. There are demands for HTML experts and HTML isn't hard. If there are demands for Hibernate, this is because alot of people want it and they want people who understand how to use it. If you want to create a framework, go for it. The issue, perhaps, is that, you don't let your technology speak for you. If your tool is superior to Hibernate or IBATIS, the market will find this out. From what I've read, I don't think that this is the case, and it has nothing to do with whether or not Hibernate is perfect. It has everything to do with your technology. Just my 2 cents...
  35. Re: No thanks[ Go to top ]

    You think Hibernate is perfect and there are a lot people with you.
    Tell me where I said that! Hibernate is not perfect, it's just vastly superior to any other ORM out there.
    I think Hibernate is not good enough and I am piching to people would agree with me. If I don't see the shortcomings of Hibernate in complex enterprise applications.
    You have also proven that you don't really understand Hibernate (like claiming it has a N+1 problem). That means you have a dubious strategy of making a new framework, based on the misunderstanding of how other frameworks work.
    Hibernate is a good product. I am totally with you. It is the best of all ORM offerings (hope not affending TOPLink people). It gives you a sense of quality. It is embraced by a lot developers, like you. However, it is an ORM soltuion, and ORM solution has limitations
    And your solution does not have limitations? Congrats!
    , although the limitation may not be as bad as the Vietnam of Computer Science as Ted Neward has put it.
    I actually TOTALLY agree with Ted Neward. I prefer working with real object databases, including Cache, ObjectStore and Db4o. HOWEVER, in the real world, customers has paid $$$ for their database systems. They want to leverage that investment, and they have a lot of knowledge about it. So we have to deal with RDBMS in the forseeable future, and for that, I believe ORM's are now good enough for most cases. For the corner cases, a plain old JDBC solutions seems more right than SavePoint, which to me falls between two chairs.
    The first softspot of Hibernate, as I see, is the query, the complex query in enterprise settings. Do you see the post by Joel Schilling. For a not-that-complex query, you need to create a view. Does the view need to be maintained?
    Views are not required, hence I do not have to maintain it.
    Do I need a view for each not-that-simple query I need to do?
    No, that's bullshit.
    How do I control the performance of the view? The database will automatically takes of care of that. Do you see it always happens from your own DBA experience?
    Stop the rant about views.
    The second softspot of Hibernate is the steep learning curve.
    With a mapping tool (like our generator), I'd imagine most programmers would find it easier and more powerful than the idiotic idea that is SQL-in-XML.
    Is there anyone who says Hibernate is easier to learn than iBATIS? Do you know there are demands for Hibernate experties and Hibernate consultants? Anything that requires experties and expert consultants, to me, that is a sign that the stuff is not simple. Period.
    We have a lot of juniors, and they have ZERO problems using Hibernate. It's a straightforward API. If you find using Hibernate intellectually challenging, maybe you shouldn't be writing persistence frameworks...
    However, Java persistence should not be that complicated,
    If you want utter simplicty, use a OO database. If you want RDBMS and utter simplicty, use Hibernate.
    there must be a simple or simpler solution. That is what SavePoint tries to find.
    I'm sorry. SQL in XML. You failed with the "simpler" part IMHO.
  36. Re: No thanks[ Go to top ]

    Hibernate is not perfect, it's just vastly superior to any other ORM out there.
    Totally off-topic but if you make such sweeping statements then expect people to correct you. There are a lot of "other ORMs" (that arent SavePoint) and they ALL have their pluses and minuses. There are persistence specifications that "your favourite" doesn't follow, which other ORMs do. There are inbuilt types that other ORMs provide that your favourite doesnt. There are mapping capabilities that other ORMs provide that "your favourite" doesnt. There are performance aspects that other ORMs provide that "your favourite" doesnt. This doesnt make Hibernate vastly superior to anything, nor any other ORM vastly superior to Hibernate. It simply demonstrates that there are many aspects to ORM and that there is no perfect solution and no justification for your statement. Many people prefer other ORMs for their own reasons. Kindly just stick to the facts.
  37. Re: No thanks[ Go to top ]

    Totally off-topic but if you make such sweeping statements then expect people to correct you. There are a lot of "other ORMs" (that arent SavePoint) and they ALL have their pluses and minuses. [...]This doesnt make Hibernate vastly superior to anything, nor any other ORM vastly superior to Hibernate.
    With that kind of logic, we can take a few words out of the dictionary. There are multiple search engines out there, all with their plusses and minuses. There is a ton of stuff that Google can't do, but I think most people would agree it is still the superior search engine. Basically because there is a couple of "pluses" that count so much more than anything else (in Google's case, coverage and performance) In the same way I *do* find Hibernate the superior open source ORM choice (there may be better commercial ones - don't care). The "pluses" that makes Hibernate superior is its good mix of versability, simplicity, scalability (with the help of Shard) and modelling power. You can find other measurable characteristics, but I do believe these are the ones that matter for most people choosing an ORM. The perfect ORM is actually no ORM (OODB), but that's not typically an acceptable option yet because of leverage, legacy, existing tools, whatever.
    Kindly just stick to the facts.
    Exactly what I did, and based on those facts, I deduced.
  38. Re: No thanks[ Go to top ]

    In the same way I *do* find Hibernate the superior open source ORM choice (there may be better commercial ones - don't care)
    Well, it was not exactly clear from your post that **you** do find Hibernate etc... Guido
  39. Han Theman[ Go to top ]

    Hey Han, did Ken kick your dog or something?
  40. Re: No thanks[ Go to top ]

    Don't use my post as an argument that Hibernate is not good enough to handle simple cases. My suggestion to use a View was a simple alternative to dropping Hibernate and using iBatis. The other solutions obviously include: 1. Refactoring the database to allow a simpler mapping in Hibernate. 2. Change your domain model to allow simpler mapping in Hibernate. 3. Create a more complex mapping in Hibernate (yes it is possible) and keep domain model the same, and the database the same. Obviously, the very best solution is a new project with a new database is to design the domain model and the database to avoid these problems. My suggestion was based on the assumptions that the database structure could not be changed, and the desire to avoid complex (and potentially time consuming) hibernate mappings. Being a software developer is all about choices and alternatives. Weighing the good and bad of each decision to try to come up with good compromises. In this situation you developed a solution to try to avoid pitfalls in Hibernate and iBatis. Unfortunately your project has the huge downside of falling into the very pitfalls that most of started using Hibernate to avoid in the first place.
  41. Re: No thanks[ Go to top ]

    Unfortunately your project has the huge downside of falling into the very pitfalls that most of started using Hibernate to avoid in the first place.
    Many things you said make sense. However, what are the very pitfalls you are talking about? Can you elaborate? Are they also in iBATIS?
  42. Re: No thanks[ Go to top ]

    I remember attempting to find good ORM solution a good couple years back....at the time there was TopLink, I believe Sun was coming out with JDO,etc., i remember going with EJB(entity beans)..bad move., anway my follow co-worker on separate project build his project on a new ORM solution called "Hibernate".... few years later,.Hibernate has now be accepted by many small to mission critical systems including myself, not because of a luck, it is simply a good component and it stood the test of time .....what you did wrong Ken in my opinion,in your sales pitch you criticize a proven tool that many season developers here have in there "skill tool box" ...I also think most of your reason on developing such a frame work is from not really knowing how Hibernate works(i don't think you used it much)..i think u had your head in the sand banging out a product that someone already did better..I am not saying NOONE cannot build a better already proven component..instead of developing something that will address an area in development of system that is "less traveled"...instead it got the typical groan of "Not another framework" response...
  43. Too thin a wrapper[ Go to top ]

    SQL, and all persistence details for that matter, should be externalized;
    Well, Hibernate does exactly that.
    Developer, rather than the persistence framework, should have the ultimate control of the SQL;
    This contradicts the first point in a way... And if you want to have ultimate control of SQL, why not just use straight JDBC in DAOs using well-known enterprise patterns?
    Writing SQL is easier than writing HSQL or QL;
    No, because SQL varies between dialects - a variation that the more generic query languages like HQL are apt at hiding. And it's not easier than writing Java code using Hibernate's Criteria. I haven't needed to write much HQL for months now thanks to the ability to use Criteria and the associated classes to express a query in Java.
    Plus it supports or plan to support recursive structure, blob and clob, inheritance and polymorphism, connect-by query, object type and other features that are useful to enterprise applications.
    So it is less feature-complete than Hibernate 3?
    Enterprise application is too complicated
    Then why don't you switch to writing applets instead and leave enterprise apps to the rest of us? :)
    O-R mapping is simply not flexible enough to cover all the needs.
    No, but it's good enough that alternatives like OO databases largely have failed.
    In the space of relational database, SQL is the king, not Hibernate.
    So what? I want to express an object model in my code and work with that. That SQL is used underneath is something I do not want to have to deal with, the same way I can write a Swing application and not have to worry (much) about graphical primitives, framebuffers etc. Hibernate offers and abstraction layer where someone else - the framework developers - worry about the plumbing.
    Second, it adds little on top of JDBC, it passes through the SQL, and transforms the SQL result set into structured objects. It does only what a JBDC developer would hope the engine to do, no more.
    Then why would anyone choose it over straight JDBC? Whoo, instead of writing code to traverse a ResultSet I get to write as much text in an XML document instead!
    It is for people who are seriously searching and evaluating solutions for their current or future persistence needs, especially in the context of enterprise applications.
    Ah, more salesman talk. Are you sure that is going to fly in this crowd?
  44. Re: Too thin a wrapper[ Go to top ]

    I think it is more appropriate to compare SavePoint With iBatis. If you want to compare this project with Hibernate, i reckon you should compare SQL with ORM. I've come across a situation that hibernate is not suitable for my project and I use iBatis intead. Basically, the data of my model (DDD) comes from different table (legacy application), I also need to perform some db operation (e.g avg()) and set it to my model. e.g Class Person { private String Name; <- Table Person private String Role; <- Table Role private Double TotalIncome <- Table sum(Person join Income join some otherTable) } I did't think hiberate is suitable for the above situation and I decided to use iBatis intead. P.S. I'm a big ORM/Hiberante fans
  45. Re: Too thin a wrapper[ Go to top ]

    I think it is more appropriate to compare SavePoint With iBatis. If you want to compare this project with Hibernate, i reckon you should compare SQL with ORM.

    I've come across a situation that hibernate is not suitable for my project and I use iBatis intead.

    Basically, the data of my model (DDD) comes from different table (legacy application), I also need to perform some db operation (e.g avg()) and set it to my model.

    e.g

    Class Person {
    private String Name; private String Role; private Double TotalIncome
    }

    I did't think hiberate is suitable for the above situation and I decided to use iBatis intead.

    P.S. I'm a big ORM/Hiberante fans
    Nathan MA, Hibernate can also map to Views as well as Tables. In this case, I would make a denormalized Person View and have the Hibernate mapping to the View.
  46. Re: A Clarification (cain't resist)[ Go to top ]

    Thanks for all your comments, although some of them ARE brutal.

    Clearly, SavePoint is not for every body, and especially it is not for those who prefer to stay away from SQL.
    and oh, this un here...
    Developer, rather than the persistence framework, should have the ultimate control of the SQL;
    Now As I sayed earlier - "If you'uns like to micro-manage boring SQL statements and mappings, yall izz gonna luv usin this here framework." Yer silly defense of the rashunayell behin this here StalePoint jus' ain't good nuff. This crowd has gots tuh be brutal on yuh, cuz with young'uns like yerself resolvin problems that is wayell solved, then we izz never gonna move forward collectively. And won last critique of yer deefense...
    However, it is hard to imagine that you could avoid SQL completely when dealing with relational database, especially in the context of enterprise applications. After all, it is the language the relational database speaks.
    With this here statement of yers, now you izz suggestin tuh most of us that you ain't well sperienced nuff in writin enterprisey-like apps in Java. Fer the last, oh, 5 years er so, ORM is where this here community is said we izz goin. And as izz posted elsewhar in this discushun, thuh availubull solueshuns provide mekanismz fer a writin strait SQL. You gonna have to find thuh small gaps that ain't well solved yayett in this here space if yuh wunts fame and fortune roun' yer Java code, sonny.
  47. Good English...[ Go to top ]

    I can't stop laughing... I wish you would do an entire blog using the lingo... I could stay entertained for hours... Keep it coming!!! 'water go down the hole....
  48. More about N+1[ Go to top ]

    • It completely avoids the N+1 problem, even in the case of deep and wide persistence objects
    Please me tell more. From my experience, there are two good solutions: outer join all tables in the hierarchy or load each level of hierarchy with a "Select ... Where parent_id in (:parent_key1, :parent_key2..., :parent_keyN)". Both have their pros and cons. (There's also two dysfunctional cases: straight 1+N and "1+1+N+1" - loading the second level with a single statement, but failing to do so for the third). It looks like SavePoint has special support only a limited form of the first approach from http://savepoint.ytzsys.com/docs/UserGuide.htm#_Toc163494279 . I say limited as I don't know if you can use the same column naming convention (such as "orders.lines.item.itemId") for outer joins, i.e. when there are order lines without items that must be loaded.
  49. Re: More about N+1[ Go to top ]

    From my experience, there are two good solutions: outer join all tables in the hierarchy or load each level of hierarchy with a "Select ... Where parent_id in (:parent_key1, :parent_key2..., :parent_keyN)". Both have their pros and cons.
    SavePoint encourages use of the first approach, although the second approach is also supported. The second approach essentially reduces the N+1 problem to 1+1 problem. The cons are: 1) additional code and query (compared to first approach) 2) limited ids you may pass into the follow-up query (1000 in oracle?) The first approach is efficient in terms of both coding and performance. The difficulty is in transforming the result set into the structured domain objects (anything else?). With SavePoint, it completes this transformation automatically for you. This is the unique strength of SavePoint, which I do not see in any existing frameworks, including hibernate and ibatis. (sorry for the sales-like talk, but this is one of main motivations behind SavePoint.)
    There's also two dysfunctional cases: straight 1+N and "1+1+N+1" - loading the second level with a single statement, but failing to do so for the third).
    SavePoint tries to let you to do it at all levels. I am attaching an example at the end of my comment. It is more complex than the exmaple you see in our site. It is a simplified version (for my testing purpose) of a real production example, tested in MySQL.
    It looks like SavePoint has special support only a limited form of the first approach from http://savepoint.ytzsys.com/docs/UserGuide.htm#_Toc163494279 . I say limited as I don't know if you can use the same column naming convention (such as "orders.lines.item.itemId") for outer joins, i.e. when there are order lines without items that must be loaded.
    I forgot about out-join thing in my example. You can do the same in query with outer joins. To SavePoint, what matters is result, not how or where it is retrieve. I guess your concern is that outer-join may results in nulls in lines and item columns. SavePoint can (at least it is expected to) handle that situation. Please see the example below. Here is the example. I am not including the table and class definitions. I hope you can figure that out from the persistence instruction. I am sorry that I have problem to format the code better in the post. You have to reformt it, by copying and pasting the code in your own editor. Thanks for your questions. <!--?xml version="1.0" encoding="ISO-8859-1"?--> Select menu books select mk.menu_book_id As "books.menuBookId", mk.name As "books.name", m.menu_id As "books.menus.menuId", m.name As "books.menus.name", m.active As "books.menus.active", current_timestamp As "books.menus.startDate", mi.menu_item_id As "books.menus.items.itemId", mi.name As "books.menus.items.name", n.nutrition_id As "books.menus.items.nutritions.nutritionId", n.name As "books.menus.items.nutritions.name", n.unit As "books.menus.items.nutritions.unit", n.quantity As "books.menus.items.nutritions.quantity", p.price_id As "books.menus.items.prices.priceId", p.size As "books.menus.items.prices.size", p.price As "books.menus.items.prices.price" from menu_book mk left outer join menu m on mk.menu_book_id = m.menu_book_id left outer join menu_item mi on m.menu_id = mi.menu_id left outer join item_nutrition n on mi.menu_item_id = n.menu_item_id left outer join item_price p on mi.menu_item_id = p.menu_item_id where mk.location_id = 1;
  50. heh heh[ Go to top ]

    From the page referred to in an earlier post: http://savepoint.ytzsys.com/?page_id=30, "To insert the Person object, you write an inert instruction as:" "inert" indeed... ;-)
  51. Re: heh heh[ Go to top ]

    Thanks for pointing it out. It was my ignorance.
  52. Re: heh heh[ Go to top ]

    I see you made the correction. Fast work. :) Sorry that it's been a rough road for you in this thread, but don't focus on the harshness of the comments but rather the usefulness of the feedback, because indeed some valid points are made. Cheers Fred
  53. Re: heh heh[ Go to top ]

    Thanks. I am tring.
  54. Re: heh heh[ Go to top ]

    Again wrong. I mean trying.
  55. Hibernate[ Go to top ]

    If you don't like this product, don't use it. I've been on projects where all SQL was stored in an XML file, and we had no problems. WOW, the Hibernate natzis are out in force. Isn't the Hibernate project associated with the JBoss project? The same JBoss project that was found astroturfing all over the net? http://yro.slashdot.org/developers/04/05/18/2043206.shtml Sometimes I wonder if the blind fanaticism displayed by the Hibernate natzis is somehow associated with that... lol
  56. Re: Hibernate[ Go to top ]

    I agree. The arrogance displayed of the Hiberate proponents on this thread does Hibernate no favours. For me, when I read stuff like that, I immediately treat what they are saying with suspicion (or a least question why they are saying it in such a manner).
  57. Re: Hibernate[ Go to top ]

    I wonder if the blind fanaticism displayed by the Hibernate natzis is somehow associated with that...

    lol
    No, I'm no Hibernate nazi. I don't even care about the project *that* much. It's just that the unfair bashing of it got me infuriated since it's actually a very good piece of technology. And you know what they say... it takes a real nazi to spot a fake one.
  58. Re: Hibernate[ Go to top ]

    Isn't the Hibernate project associated with the JBoss project? The same JBoss project that was found astroturfing all over the net?
    Hibernate recently because associated with JBoss, it wasn't always the case.