I'm experiencing the same problem, but I'm not sure how to fix it. I'm using MyEclipse 2020.9.16, Spring 4.1 and Hibernate 4.1. I used reverse engineering to generate DAOs and POJOs against an already existing database. In particular I am having a problem extracting data from a view that does not contain an ID field, and I cannot modify the database. In reverse engineering, MyEclipse has created a view POJO, a view Abstract POJO, a viewId POJO, and a view DAO.
Relevant piece of View DAO (the function that fails when called because while the List has the appropriate number of objects, they're all null)
How it is called (and throws a NPE)
So, is there any way to fix this without starting over from scratch?
I looked for table relationships (OneToMany/ManyToOne and so forth) and didn't see any (then again, my vision is awful these days). That's where I'd usually expect trouble. If a primary query returned null, you could simply test, but normally I'd expect an empty collection to come back.
A primary concerrn, however, is this View that "has no ID". If your View has, in fact, no column with unique values, I'm not even sure JPA can handle that. JPA uses the primary key to determine what instances of a particular Entity correspond to the same row in the database, since JPA can often have multiple copies of a row (espeicially if it's being modified in RAM). In such a case, you're either going to have to use an alternative access method (like raw JDBC) or have the View definition modified if, in fact there is a unique column in the view. You should be able to to this in the JPA annotations even if the database schema doesn't allow for it, although you could encounter problems if someone managed to violate uniqueness in the View at some future date (in other words, while you can make up for database schema deficiencies, it's better if the DBA does it instead).
Sources may include data from the Fakebook Research Foundation with support from Gargle University
So, the view itself is a merging of three tables: AREA, USER, and USER_AREA_ACCESS (UAA). I removed some of the code from my previous post to fit the character limit, but these three tables are joined where the AREA_ID and USER_ID fields are found in UAA, and UAA has an ID field as well that could be used as the Primary Key of this view. I'll see if I can't use that. Thanks!
Forget this weirdo. You guys wanna see something really neat? I just have to take off my shoe .... (hint: it's a tiny ad)