Java ORM POJO design pattern problem

I have general problem that for now I didn't saw any ORM that solve it, I have an entity in the database that have fields that I didn't want to load them from database because performance issues, Now if I didn't load them in the SQL query so they 开发者_开发技巧get a default value (NULL), and someone can use this property and cause a bug, and if I create a new POJO for that result set, the code will contains a lot of "waste" POJO's that cannot be reused...

I already think on lazy initialization, but what's happened if I read list of POJO's once and than for each element I try to use the uninitialized field - that's will cause a lot of database connections and time load...

What's is the best design pattern to solve this issue?

Thanks!!!

---

Hibernate allows to set any property to "lazy". It will then instrument the class bytecode to load these fields on demand. As you noticed, that can be pretty expensive.

One solution is to split your objects into two classes A and B where B extends A. For the simple tasks, you tell the framework to load A (with only a few fields). Then you select all those elements you need and use the IDs to load the B's. Since you use the primary key, this is pretty fast. But you will have the overhead that the fields in A will be loaded twice.

Another solution is to use HQL to load the properties you need. If you mention a column in HQL, it will be loaded, no matter what the lazy option says. But you will get a new list of objects where just those properties are set. That means you will have to merge manually.

Conclusion: There is no simple, out-of-the-box solution that makes everyone happy. The reason for this is that Java is no DB (you can't run selects against your object model in RAM) and the DB works completely different than Java when it comes to managing rows. This schism is unresolvable and all OR mappers suffer from it.

Object DBs are a bit better in this regard but they need hacks to search objects (like "all elements in a list which have the name 'John'.")

NoSQL DBs don't have the problem because each row is "key:value" and you have to emulate the concept of "column" by building the "key" in a useful way (like "User:1:name" which is the name of a User instance with the ID 1). Here, joining values is hard.

Q: Why do we have more than one database?
A: Because they all suck.
-- A. Digulla