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).
Loudly announcing something is true and finding out you're wrong makes you feel foolish.
Finding out you're wrong and refusing to admit it makes you LOOK foolish.
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!
On my planet I'm considered quite beautiful. Thanks to the poetry in this tiny ad: