I want to implement a hotel booking system with Play framework 2.0 (Java). The app will do hotel booking with no banking transactions (credit card will be provided only as identification method to prevent fraud), user will select the desirable room and date range and the app will make the booking and update the rooms availability.
I am considering mongo over mySQL for performance reasons and also because my models will have translatable fields in a few languages which will have a lot of joins if it is in mySQL.
For Availability check I don't quite figure it out, if it is simpler in mySQL rather than mongo.
Is MongoDB suitable for that kind of web app, or I am in the wrong path?
Two simple statements :
Stick with what you know. If you know plain SQL, go for that.
Premature optimization is the root of all evil. If even before starting your application, you are already thinking of optimization, there is something terribly wrong with your way of working.
You can use mongoDB for this kind of application. I personally have some security concerns when it comes to sensitive data (i.e. credit card infirmation) as deleting the information does not automatically mean that it is unrecoverable.
From wikipedia on MongoDB:
E-commerce. Several sites are using MongoDB as the core of their ecommerce infrastructure (often in combination with an RDBMS for the final order processing and accounting).
There are some very intresting articles on pros an cons on stackoverflow Pros and cons of MongoDB?
If you want to learn a new NoSQL technology by all means go for it, but if you want to play it safe stick to the mysql solution. These applications (booking) often work well with BI solutions/data mining and this fact alone would make a noSql approach a no-go for me.
we use Hibernate Search in our application. We use faceting. Recently we have found a big limitation. Faceting over fields that can have multiple values doesn't work properly with Hibernate Search - if a document has multiple values for faceted field (ex. multiple categories), only one of the values is taken into account.
I can currently think of a couple two solutions:
use bobo-browse (http://code.google.com/p/bobo-browse/)
solr (http://lucene.apache.org/solr/)
In both solutions we continue to maintain the index using Hiberante Search and making queries as we did before (using Hiberante Search), and run additional bobo-browse or solr query for faceting, where required (bobo-browse or solr would use index in kind of "read-only" manner). The problem is that we update index quite often, and would like to get really fresh data in faceting queries. Bobo-browse doesn't automatically integrate with Hiberante Search, and to keep search up to date, I might get into some problems (ex. https://groups.google.com/forum/?fromgroups=#!topic/bobo-browse/sn_Efc-YClU). The documentation looks a bit untidy and not yet completed. Solr on the other hand seems like a really big thing to add, just to get faceting work properly. And I'm still afraid I might run into some problems with updating/refreshing index.
Do you have any experience in that matter? Any suggestions?
As a Hibernate Search developer, I'd suggest to join us and help implement what you need.
Noone of us actually needed multivalued faceting so we're not really sure which solution to pick either; it seems you have a real need, that's perfect to explore the alternatives and try them out.
Hibernate Search already depends on many Solr modules especially because of the large collection of excellent analysers. I'm confident we could find a way to embed the faceting logic of Solr and package it nicely in our consistent API, without the need to actually start Solr in server mode.
I guess we could do the same with Bobo-browse; I'd prefer Solr to not add other dependencies, but if bobo-browse proofs a superior solution why not.. but you can help us in this choice.
What would you get in exchange?
we'll maintain it: compatibility will stay with any future version. hopefully you'll help a bit.
eternal gratitude from other users ;)
rock solid testing from thousands of other users
bugfixes and improvements from ..
a rock star badge on your CV
What is required?
unit tests
documentation updates
sensible code
https://community.jboss.org/wiki/ContributingToHibernateSearch
I also use Bobo Browse in combination with Hibernate Search. I also have the problem with regular updates and the read-only issue. Bobo is not the easiest library out there and I've looked several times at ways to integrate with Hibernate Search and just gave up because of the complexity.
I use timed reloads of the index in order to ensure freshness but that creates a lot of garbage to be collected. Lucene has over time optimized the process of reopening indexreaders, but the Bobo team is not really focused on supporting that. https://linkedin.jira.com/browse/BOBO-31 describes this issue.
The Hibernate Search infrastructure should provide enough flexibility to integrate. Zoie is a real-time indexing system like Hibernate Search that is integrated with Bobo https://linkedin.jira.com/wiki/display/BOBO/Realtime+Faceting+with+Zoie Perhaps it can inspire your efforts
This is something of a solution to the multi-value facet-count problem for hibernate-search.
Blog: http://outbottle.com/hibernate-search-multivalue-facet-counts/
The blog is complete with a Java Class that can be reused to generate facet-counts for single-value and multi-value fields.
The solution provided is based on the BitSet solution provided here: http://sujitpal.blogspot.ie/2007/04/lucene-search-within-search-with.html
The blog has a Maven project which demonstrates the solution quite comprehensively. The project demonstrates using the hibernate-search faceting API to filter on....
a date-range AND a 1-to-many (single-value) facet-group AND a many-to-many (multi-value) facet-group combined.
The solution is then invoked to correctly derive facet-counts for each facet-group.
The solution facilitates results similar to this jsFiddle emulation: http://goo.gl/y5C9UO (except that the emulation does not demo the range faceting).
The jsFiddle is part of a larger blog which explores the concept of facet searching in general: http://outbottle.com/understanding-faceted-searching/. If you’re like me and are finding the whole notion of facet-searching quite confusing then this will help.
It may not be the best solution in the world so feel free to feedback.
A few months ago I created a shop manager software for one of our customers.
One of the requirements was Adobe ColdFusion. Nevertheless, I came up with a really nice product, simple and fast, a few nice ideas and some positive feedbacks.
Now I think I am ready for letting "bigger" customers see my project.
I prefer not to write that next version in ColdFusion, I'm looking for something much more scalable and reliable.
The cloud computing, actually, is making me really curious! In particular, Google AppEngine seems to have all I need:
I know Java
I could start from scratch, without paying anything
It's Google, what's more reliable than it?
I made a few helloworld-s, looking for the best technology to use.
GWT is really nice, but my dev team loves html+css "page centric" apps, so I think it would be a too high jump. Instead of it I was considering:
Spring MVC 3.x
Objectify 4 (as a persistence manager, instead of JDO/JPA)
My questions are:
Based on your experiences, do you think that GAE is suitable for developing and hosting a "shop manager" software, which will manage tables (CRUD), make reports, and so on? My projects is really simple.
Do the two technology I mentioned are good and enough for such a project? What will I need in addition?
I've made an pretty standard shop, using: Appengine + Spring + Groovy + Objectify (and backbonejs + google closure templates for client side)
And from my experience I can say:
It's possible :)
Such system requires a lot of transactions - it's possible, but not so trivial using appengine. There is a lot of transactions, and a lot of work
Reports is better to prepare on background (taskqueue/cron/prospectivesearch), and it's hard to prepare 'on-demand' or custom reports (actually it's must be done on background anyways)
I'm happy with my current implementation, but I see that using an standard RDBMS fits much better for this type of projects.
PS And also, you can take a look at CloudFoundry, I didn't tried it yes, but seems that it's good thing too and it have PostreSQL as service
Someone please help me in choosing whether to use Hibernate or Cayenne?
Which is more suitable to handle large databases?
I used both, but if I was in charge (and not my boss :) ) I would prefer Cayenne.
Cayenne has a very nice CayenneModeler, so you don't have to write any mapping code - just click your way an entire project in a few minutes.
If you have performance sensitive areas in you project, Cayenne has something called SQLTemplate - a very very efficient solution.
And last but not least, as a newbie or as a simple user, you get very fast very good solutions to your questions - as opposed to the Hibernate forums - just look how many questions are unanswered there.
Bill Dudney -
Overall in my limited expierence
Cayenne is a robust and fun framework
to develop with. There are lots of
cool features and if you know
Hibernate its a small leap to grok
Cayenne. Cayenne seems to have a
vibrant community of users and the
list was very friendly and answered my
simpleton questions quickly and
without trying to make me feel stupid.
Cayenne seems to be a bit less mature
than Hibernate in a few areas, for
example, the distributed caching is
new in version 1.1. In general though
Cayenne is a great framework and I
would definitely recommend that you
take a look at it when you start your
next project that requires an ORM
framework.
This discussion on relative strengths or Hibernate vs. Toplink offers few important point an which features to look when evaluating:
http://programming.itags.org/development-tools/120839/
My developers are waging a civil war. In one camp, they've embraced Hibernate and Spring. In the other camp, they've denounced frameworks - they're considering Hibernate though.
The question is: Are there any nasty surprises, weaknesses or pit-falls that newbie Hibernate-Spring converts are likely to stumble on?
PS: We've a DAO library that's not very sophisticated. I doubt that it has Hibernate's richness, but it's reaching some sort of maturity (i.e. it's not been changed in the last few projects it's included).
They've denounced frameworks?
That's nuts. If you don't use an off-the-shelf framework, then you create your own. It's still a framework.
I've used Hibernate a number of times in the past. Each time I've run into edge cases where determining the syntax devolved into a scavenger hunt through the documentation, Google, and old versions. It is a powerful tool but poorly documented (last I looked).
As for Spring, just about every job I've interviewed for or looked at in the past few years involved Spring, it's really become the de-facto standard for Java/web. Using it will help your developers be more marketable in the future, and it'll help you as you'll have a large pool of people who'll understand your application.
Writing your own framework is tempting, educational, and fun. Not so great on results.
Hibernate has quirks to be sure but that is because the problem it is trying to solve is complex. Every time someone complains about Hibernate I remind them of all of the boring DAO code that they would have to maintain if they weren't using it.
A few tips:
Hibernate is no substitute for a good database design. Hibernate schemas are OK but you will have to tweak them occasionally
Eventually you are going to have to understand how Hibernate lazy loads classes and how that affects things. Hibernate modifies the Java bytecode and you will need to delve into the depths sooner or later if only to explain why object links are null.
Use annotations if you can.
Take the time to learn the Hibernate performance tuning techniques, it will save you in the long run.
If you have a fairly complex database, Hibernate may not be for you. At work we have a fairly complex database with lots of data, and Hibernate doesn't really work for us. We've started using iBATIS instead. However, I know a lot of development shops who use Hibernate successfully - and it does do a lot of grunt work for you - so it's worth considering.
Spring is a good tool if you know how to use it properly.
I would say that frameworks are definitely a good thing - like others have pointed out, you don't want to reinvent the wheel. Spring contains a lot of modules which will mean you won't have to write so much code. Don't succumb to the "Not Invented Here" syndrome!
Lazy loading is the big gotcha in MVC applications that use Hibernate for their persistence framework. You load the object in the controller and pass it to the JSP view. Some or all of the members of the class are proxied and everything blows up because you Hibernate session was closed when the controller completed.
You will need to read the Open Session in View article to understand the problem and get a solution. If you are using Spring the this blog article describes the Spring solution to the open session in view issue.
This is one thing (I could remember) that I fell into when I was in my Hibernate days.
When you delete (several) child objects from a collection (in a parent entity) and then add new entities to the same collection in one transaction without flushing in the middle, Hibernate will do "insert" before "delete". If the child table has a unique constraint in one of its columns, and you are expecting that you would not violate it since you have already deleted some data before (just like I was), then get ready to be frustrated.
Hibernate forum suggests:
It was a DB design flaw, redesign;
flush (or commit if you will) in between the deletes and inserts;
I couldn't do both, and end up tweaking the Hibernate source and recompiling. It was only 1 line of code. But the effort to find that one line was equal to approximately 27 cups of coffee and 3 sleepless nights.
This is just one example of problems and quirks you might end up when using Hibernate with no real expert on your team (expert: someone with adequate knowledge about the philosophy and internal working of Hibernate). Your problem, solution, litre of coffee, and sleepless night count may vary. But you get the idea.
I haven't worked much with Java but I did work in large groups of Java developers. The impression I've got was that Spring is OK. But everybody was upset at Hibernate. Half the team if asked "If you could change one thing, what would you change?" and they'd say "Get rid of Hibernate.". When I started to learn Hibernate it struck me at amazingly complex, but I didn't learn enough (thankfully I've moved along) to know if the complexity was justified or not (maybe it was require to solve some complex problems).
The team got rid of Spring in favor of Guice, but that was more like a political change, at least from my point of view and other developers I've talked to.
I have always found Hibernate to be a bit complex and hard to learn. But as JPA (Java Persistence API) and EJB (Enterprise Java Beans) 3.0 has existed for a while things have gotten a lot easier, I much prefer annotating my classes to create mappings via JavaDoc or XML. Check out the support in Hibernate. The added bonus is that it is possible (but not effortless) to change the database framework later on if needed. I have used OpenJPA with great results.
Lately I have been using JCR (Java Content Repository) more and more. I love the way that my modules can share a single data storage and that I can let the structure and properties evolve. I find it a lot easier working with nodes and properties rather that mapping my objects to a database. A good implementation is Jackrabbit.
As for Spring, it has a lot of features I like, but the amount of XML needed to configure means I will never use it. Instead I utilize Guice and absolutely love it.
To roundup, I would show your doubting developers how Hibernate will make their life easier. As for Spring I would seriously check if Guice is a viable alternative and then try to show how Spring/Guice makes development better and easier.
I've done a lot of Spring/Hibernate development. Over time the way people used both in combination has changed a bit. The original HibernateTemplate approach has proved to be difficult to debug since it swallows and wraps otherwise useful exceptions; talk to the Hiberante API directly!
Please keep looking at the generated SQL (configure your development logging to show SQL). Having an abstraction layer to the database doesn't mean you don't have to think in SQL anymore; you won't get good performance if you otherwise.
Consider the project. I've choosen iBatis over Hibernate on several occasions where we had stringent performance requirements, complex legacy schemas or good DBa's capable of writing excellent SQL.
As for Hibernate: a very good tool for application which deals with a rapidly changing database schema, a large amount of tables, do lots of simple CRUD operations. Reports with complex queries involved are rather less well handled. But in these case I prefer mixing in JDBC or native queries. So, for a short answer: I do think time spent learning Hibernate is a good investment (they say it is compliant with EJB3.0 and JPA standards, also, but that didn't come into the equation when I evaluated it for my personal use).
As for Spring... see The Bile Blog :)
Remember: frameworks are not silver bullets, but you should not reinvent the wheel either.
I find it really helps to use well-known frameworks such as Hibernate because it fits your code into a specific mold, or a way of thinking. Meaning, since you're using Hibernate, you write code a certain way, and most if not all developers who know Hibernate will be able to follow your line of thinking quite easily.
There's a downside to this, of course. Before you become a hot shot Hibernate developer, you're going to find that you're trying to fit a square into a circular hole. You KNOW what you want to do, and how you were supposed to do it before Hibernate came into the picture, but finding the Hibernate way of doing it may take... quite a bit of time.
Still, for companies that frequently hire consultants (who need to understand a lot of source code in a short amount of time) or where the developers sign on and quit frequently, or where you just don't want to bet that your key developers will stay forever and never change jobs -- Hibernate and other standard frameworks are a pretty good idea I think.
/Ace
Spring and Hibernate are frameworks that are tricky to master. It may not be a good idea to use them in projects with tight deadlines while you're still trying to figure out the frameworks.
The benefits of the frameworks is basically to try to provide a platform to allow for consistent codes to be products. From experience, you'd be well advised to have developers experienced with the frameworks setting in place best practices.
Depending on the design of your application and/or database, there are also quirks that you'll need to circumvent to ensure that the frameworks do not hinder performance.
In my opinion, the biggest advantage of Spring is that it encourages and enables better development practices, in particular loose coupling, testing, and more interfaces. Hibernate without Spring can be really painful, but the two together are very useful.
Retrofitting an existing project to any framework is going to be painful, but the refactoring process often has serious benefits for long-term maintainability.
I have to agree with many posts on this one. I've used both, extensively, in a variety of settings. If I could undo a design decision it would be to have used Hibernate. We actually budgeted a release in one of our products to swap Hibernate for iBatis and Spring-JDBC for a best-of-all-worlds approach. I can have a new developer get up to speed using Spring-JDBC, Spring-MVC, Spring-Ioc, and iBatis faster than if I just tasked them with Hibernate.
Hibernate is just too complicated for this KISS developer. And heaven help you with hibernate if your DBA sees the generated SQL the database sees and sends you back with optimized versions.
The top answer mentions that Hibernate is poorly documented. I agree that the online reference manual could be more complete. However, a book written by Hibernate's authors, 'Java persistence with Hibernate' is a must-read for every Hibernate user and very complete.
#slim - I am with you again this morning.
It sounds like a classic case of Not Invented Here Syndrome. If they aren't keen on spring, they should consider other options rather than rolling their own framework (whether they acknowledge doing it or not). Guice comes to mind as an possibility. Also picocontainer. There are others out there, depending on what you need.
Spring and Hibernate definitely make life easier.
Getting started with them might be a little time-consuming at the beginning, but you'll certainly benefit from it later. Now the XML is being replaced by annotations, you don't need to type hundreds of lines of XML either.
You may want to consider AppFuse to reduce your learning-curve: generate an application, study and adapt it, and off you go.
Frameworks are not evil. even the Java SDK is a framework.
What they probably fight is framework proliferation. You shouldn't bring a framework to a project just for the kick of it, it should bring consistent value in a reasonable time. Every framework requires a learning curve, but should reward you with increased productivity and features later on.
If you struggle with code that is hard to debug because of inconsistent database usage, complicated cache mechanisms, or a myriad of other reasons. Hibernate will add great value.
apart from the learning curve (which took about 1 month of practical work for me) there weren't any pitfalls, provided you have someone around to explain the basics for you.