I've got involved in a project with entity manager in it. It's a bit unclear why should one use it. We have databases to store information in if we don't we can use classes to store informations in without the entity manager. The question is is it worth the effort to learn? Is it a widely used tool?
I know it's a bit opinion based but I'm interested in the facts mainly. But usually others experience shows how good a tool is.
Yes, JPA and Hibernate are widely used. Their benefits are the speed of the development (especially on the early stages of the project), but since it's a very complicated technology not everyone gets to use it effectively.
Ultimately knowing JDBC and databases is much more important than knowing ORMs. Mostly because everything else related to DBs in Java (including ORMs) is based on JDBC. But also if you need to write a very performant code - JDBC could be the right level of abstraction for you.
If you want to learn ORMs I'd advise to start with the book POJOs In Action - it explains the fundamental principles behind these frameworks. And after that check out Java Persistence with Hibernate - this one is more technically involved and describes all sorts of features in Hibernate.
Apart from the fully-featured ORMs there are lighter technologies that ease up the low-level JDBC burden: jOOQ, Spring JDBC, MyBatis.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed last month.
Improve this question
I am using Java language.I have to use ORM framework with MongoDb as Database.I have two options Morphia or Spring Data Mongo support.As far i am able to get details , it has been found Spring Data Mongo is better to use since:
1)It provides better DAO out of box inbuilt classes.
2)It has larger community base.
Are there any performance based differences between the two.And if there which one is better in which condition.Also i have requirement of multitenancy .After little search i found that there is very simple custom implementation in Spring Data Mongo to do the same.But in Morphia it is somewhat difficult.Does achieving multitenancy in Morphia diificult(where we need to write a lot of boiler plate code)
I have been using Spring-data and I guess I feel somehow it lags as far as maturity is concerned.
It's good for all the practical purposes but the features mongo provides in it's full glory, Spring-data is slow to map that as a driver specially when it comes to aggregation.
As far as performance goes, Spring-data doesn't lag imo.
Sometime I get weird behaviors. Some of their annotation silently doesn't work at some places and for my life I cannot figure out why?
But as an overall implementation it's quite helpful in the way that it provides a robust structure on which your application can grow. It also is easy if you are coming from SQL background since you can draw a parallel between jdbcTemplate and mongoTemplate (though one needs to be cautious)
I seriously considered using Morphia, but dropped the idea since spring-data was providing a more structured ways. Looks like in Morphia we would have to implement some structure on our own which has pros and cons but You usually want to avoid doing it. Since there is a risk of boiler-plate codes, there is a learning curve for 'your' structure for new members.
On the pros side, I am sure Morphia provides more extensiblity leading you to enjoy the ability to suck most out of mongo features. It also is lightweight compared to Spring data.
Morphia is the way to go. Pretty stable, very good Play integration and offers access to all Mongo driver features if you need more torque. Reference resolution, entity embedding are working as expected. You get lifecycle annotations too, which are pretty useful for boilerplate persistence code.
I personally like spring-data because of the hades project... You don't need to implement the DAOs. You just write the interface and spring data automatically provides it to you. However Spring Data Mongodb implementation seems a little buggy in my initial trial. If you have hard dates and is working on a production quality product, probably it is wise to choose Morphia.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Recently, I have started working on mongo. As the whole concept of mongodb is schemaless and document-oriented, how can I transition relationships to entities?
I have used hibernate ORM in java for mapping objects to tables. Is there a need to do the same for mongodb?
Things which restrict me from using OGM:
Once the Java Entity is mapped to a collection in mongo, will the concept of mongo being schemaless still be valid. In this case I have to map member variables to keys of that collection. Also if a mongo collection is supposed to contain nested objects or an array of objects, then what?
Hibernate has launched their OGM for NoSQL databases recently (January 2015).
Could anyone help me out with the decision to choose OGM for mongo?
Edit: Kundera is no longer maintained. Please use alternatives.
Of course, ORMs are easy to use and many of them allow us to use SQL or JPQL for querying in a similar way like RDBMS but ORMs have their own limitation and yeah they will add a little bit of overhead too(in terms of performance). That's why using Native MongoDB Java Driver is preferred.
For NOSQL databases, choosing an ORM purely depends upon the use case. An ORM will map your table(Collection in the case of MongoDB) to an Entity Object. You added, you can keep a map in entity which will allow your design to become a little bit of schemaless. Most of the time our data is almost structured so ORMs can be used. But if you have completely versatile and unstructured data go for Java Driver. Check Mongo's documentation.
Also, there are other stable ORM tools like Kundera, Spring Data. You should explore them.
PS:
This answer is for ORMs vs native driver not on Hibernate ORM
I am a Kundera developer
I would recommend a OGM framework like Tinkerpop, or if you need something a bit higher level and more similar to Hibernate then consider Ferma. Ferma sits on top of Tinkerpop and uses annotations to define Java classes that resemble an Entity in JPA and Hibernate. The difference is Ferma and Tinkerpop is built specifically for graph databases rather than trying to stuff it into a framework designed for traditional Relational Databases.
One nice feature of Ferma and Tinkerpop is that while built for Graph Databases they still work on Relational Databases. There are several drivers for Tinkerpop that allow it to work on virtually every major Graph Database and Relational Database on the market. It can also use in-memory drivers that exist natively in Tinkerpop and therefore doesn't need to be backed by any database at all. Its an extremely flexible platform that has a lot of benefits when it comes to modular and flexible code.
For reference here is the description of the Ferma project.
The Ferma project was originally created as an alternative to the
TinkerPop2 Frames project. Which at the time lacked features needed by
the community, and its performance was cripplingly slow. Today Ferma
is a robust framework that takes on a role similar to an
Object-relational Model (ORM) library for traditional databases. Ferma
is often referred to as a Object-graph Model (OGM) library, and maps
Java objects to elements in a graph such as a Vertex or an Edge. In
short it allows a schema to be defined using java interfaces and
classes which provides a level of abstraction for interacting with the
underlying graph.
And also the description of the Tinkerpop project.
Apache TinkerPop™ is a graph computing framework for both graph
databases (OLTP) and graph analytic systems (OLAP).
Note: I am one of the author's of Ferma.
There are many resources where you can found information. Most of them highlights only some aspects. If you want to see overall information you should read a book.
Intention of this question is provide you with some light-weight article, that nevertheless covers all basics that you need to get started.
Understanding JPA, Part 1: The object-oriented paradigm of data persistence
http://www.javaworld.com/javaworld/jw-01-2008/jw-01-jpa1.html
Understanding JPA, Part 2: Relationships the JPA way
http://www.javaworld.com/javaworld/jw-01-2008/jw-01-jpa2.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In the last time I heard a lot of complaining about Hibernate. And indeed I have some painful experiences with Hibernate too. So I read about Ebean and Siena.
Both have interesting approaches. Unfortunately, database access layers are very easy to write, but if your project grows and you have to handle great database-tables, you know if they are good or not. So it's really difficult to evaluate such a tool. Hibernate is well known and you could be sure that you can solve your problem with it. Sometime you need to learn a lot, but you can solve it.
How is it with Ebean? Are there any real world applications? Which databases are supported? Is it reliable?
After searching a little bit more I see that there are a lot more ORM-frameworks, so is there at least one reliable one?
Rob (Ebean Committer) here.
Ebean is about 4+ years old now. I would say it is fairly mature now. The supported DB's include Oracle, MySql, Postgres, H2 and SQL Server (and recently SQLite). Ebean is doing stuff that other ORM's are not such as Autofetch (automatic query tuning) so I'm not how that fit's into a 'maturity rating'. IMO the Ebean community is relatively small though so you probably need to hit the Ebean google group to engage them.
Any real world applications? Yes, but you are best to ask the Ebean community about that really. Certainly there is good support for batch processing (batch size, turn of cascading persist for a transaction etc) and large query support that I don't see in JPA etc (you might get something similar with Hibernate's Sessionless support).
Hopefully this might answer some small parts of your question anyway.
Cheers, Rob.
I'm currently a developer of Siena but not since very long. Let me explain why I became a developer on this project?
I went to Siena because I wanted to use Play+GAE and Siena appeared to be a good start for GAE DB and I really wanted to avoid JDO/JPA.
Then, I began to really appreciate Siena for its straightforward, light and easy approach and so simple APIs. It doesn't pretend to be the all-in-one abstraction layer like JDO and the greatest standard DB API like JPA. It really made me think of DB APIs from Python/Ruby and it really fits my point of view: I want a simple DB API which allows me to solve the great majority of my problems and when I have a more complex problem, I will use the lower layer APIs but certainly not an abstraction layer such as hibernate.
The possibility to make my code work on GAE DB or JDBC was also a good aspect. Once again, Siena doesn't pretend to provide exactly the same things in both worlds because SQL and NoSQL are not really compatible (but ORM is neither really compliant to SQL model :) ).
But once again, it is quite practical to be able to rely on the same APIs in several DBs.
Finally, the library is ONE jar and you don't have to retrieve the whole universe to use it.
So, I became progressively a committer on Siena because I wanted to take part of this nice little adventure.
Now siena team is working on a new version keeping the same simple APIs, bringing new interesting features and really improving all the backend code to make it even easier to extend for new DB support.
Siena is a pragmatic API driven by user experiences and that's why I like it ;)
Pascal
We've had really great experience with MyBatis, which is not an ORM per se, but another class of persistence manager, an SQL Mapper. Using it you start with SQL statements and direct it on how to map result rows into POJOs. It's conceptually easy to understand and tune with not much magic going on inside. It's ideal if you are comfortable with SQL or need to work with an established schema.
Besides Ebean and Siena:
You can try JIRM which is focused on CRUDing immutable objects (yes I'm the author).
There is also jOOQ and Joist.
I feel that JIRM minimizes the number of DTO's because the domain objects are immutable and do not inherit, implement and/or are not "enhanced/instrumented". Such is not the same with Siena and Ebean.
Also because the objects are Immutable there is more of a focus on per column updating instead of the whole object which makes more sense given today's AJAX interfaces (compared to the old POST the whole bean model).
What about using EB3, with for instance JBoss (www.jboss.org)?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are evaluating ORM solutions for my project that has tight coupling between business layer and datalayer(JDBC). I started doing a PoC with Cayenne. My requirement goes like this
a) Already there exists database schema
b) Schema is very granular level. I.e. real time java objects are only derived by combining tables.
c) At the moment I just want to perform read operation (to be precise filter and sort on a list by inputing criteria)
Till now, the observations I have made with Cayenne are
1) Table and Object are tightly coupled. Modeler is not allowing to create java object without associated table.
2) I could not find easy way to map output of a named query to a java object so that I get list in a way application needs.
3) Also I am not sure Expressions work with named queries.
I would like to know your inputs on best choice for my requirement?
Thank you in advance.
If I had to choose an ORM tool or a JPA provider, it wouldn't be Cayenne simply because it doesn't seem to be widely used so the community behind it isn't very large and this is a concern. There is thus no need to discuss technical points, things like Cayenne 2.0 is intrusive, you have to implement an interface or to extend a superclass (Cayenne 3.0 has POJO support but is still in beta, after more than 2 years...). No, really, I don't see any good reason to not pick Hibernate, the defacto standard, if you need an ORM tool.
But...
Given your requirements, an ORM might actually not be the best choice, mosty because of b) so I would consider using iBatis (which is not an O/R mapper, it's a data mapper) instead.
Cayenne has a lot of very good features, and on the plus side you have a number of open source tools to use in your project. Hibernate suits some people and Cayenne others. I know that for more own use, Cayenne was far superior to Hibernate due mainly to these factors:
a very helpful user community. Hibernate's can be a little abrasive.
a very robust code base with a large number of tests which provide large code coverage
ROP (three tier) support. This in itself is a huge feature if you need it.
good inheritance support
Cayenne modeler
Yes, the Cayenne approach is that Object Entities (the Java clients which map to the db) extend a superclass. That gives you some distinct advantages over Hibernate (Cayenne controls the entire object lifecycle) and introduces complexities for some people.
I also find the way Cayenne manages the Context (a group of objects and changes which will later be committed together) to be very intuitive.
As for your questions:
1) Cayenne definitely lets you create Object Entities without a one-to-one map to a table. We do it all the time, particularly when modelling inheritance.
2) SQLTemplate will let you get at named queries, but you'll find that most ORMs will steer you away from this approach since you are working against the natural way an ORM works to build queries directly in the database. The point is to abstract the database whenever possible.
3) SQLTemplate will let you do just about anything you want. But again, adopting an ORM is about a strategy for writing your application, not just a light wrapper for JDBC. I believe the benefits are huge and our projects have benefitted, but it depends on your goals.
Agreed, Cayenne has a lot of very good features. But if your project need some work done with inheritance(you didn't mention it), definitively Cayenne is not a option. It doesn't do a "good inheritance support":
Horizontal inheritance - https://issues.apache.org/jira/browse/CAY-795 -open since 30/May/07;
discussion Vertical-inheritance on http://cayenne.195.n3.nabble.com/Vertical-inheritance-td827636.html since 18/May/2010
I often use it on my personal projects and the gain in productivity is excellent.