Everything is working great with the tutorial except I used a mysql driver instead and when I use the persistencelayer.add(user) it seems to work but when I go to the database the data is not committed. Do I need to add some kind for transaction commit to this. Any advice would be greatly appreciated.

Quote:

Do I need to add some kind for transaction commit to this

I guess that's precisely what you need. Adding the transaction management code should do the trick for you.

I ran the first part of the tutorial (1 - 6) and it ran just fine.
However, starting at section 7 Hibernate Annotations and MyEclipse 6.5
i think there is a problem with the logic in the

BusinessLogic.java

/* 1. Create a new user */
Integer id = new Integer(1); // this uses a FIXED value for id

AbstractUser.java // where as this generates its own value ... i think
..
// Property accessors
@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "id", unique = true, nullable = false)
public Integer getId()
{
return this.id;
}


User userLoadedFromDB = persistenceLayer.findUserById(id); // id = 1
// this call returns a NULL

How can I fix the example?

Thanks

looks like in all places where you see persistenceLayer.findUserById(id)
change it to persistenceLayer.findUserbyId(user.getId())


can MyEclipse please fix the tutorial

thanks

Quote:

can MyEclipse please fix the tutorial

I have asked the dev team to fix this asap. Thank you for posting this information.

is there an example of the transaction code needed to make the tutorial application work -- that is, to commit the changes? I'm following the "hibernate & spring tutorial" at
http://127.0.0.1:54811/help/topic/com.genuitec.myeclipse.doc/html/quickstarts/hibernateandspring/index.html
and have the problem mentioned above, with the batch app, that it runs fine but the data is not left in the database.
Shouldn't the tutorial be fixed so it commits the changes?

Here is the workaround for you. Sorry for the inconvenience caused.
http://www.myeclipseide.com/PNphpBB2-viewtopic-t-19832.html

MyEclipse guys, you should fix this tutorial. I ran into the same problem, and spent hours solving it. Now I see that the problem is known since januari... doesn't feel right.

gmjonker
I'm extremely sorry you ran into this problem as well. I have just added a note to the PR that I had filed. Sorry for the inconvenience caused.

gmjonker wrote:

MyEclipse guys, you should fix this tutorial. I ran into the same problem, and spent hours solving it. Now I see that the problem is known since januari... doesn't feel right.

I too have been going through the hibernate-spring tutorial and I"ve been extremely puzzled as to why the heck hibernate-template is not committing the data PERMANENTLY into a persistent medium? It seems to really defeat the purpose (and is a misnomer) of "Java Persistence" if the data you try to insert only lasts as long as the application running?

Also this issue has been known since early 2008, and there is probally a whole slew of other users banging their heads against the wall wondering why the heck if hibernate-spring is suppose be so easy why isn't their code working? Guys it's gonna be 2009 soon so in the span of nearly a year no one could spend maybe 15 (IF EVEN THAT) minutes to make a update to the code test it and post it in the tutorials section and commit to the main cvs branch? Come on guys.

Guys, the reason this was never changed in the tutorial is because it's not a bug, it's just a conflict of applicability and actually exposes an opportunity for an enhancement here. Let me explain:

1. Our rev-eng tools never generate transaction boundries, because we have no idea what they are. That's design/application dependent.
2. The tutorial uses our straight rev-eng tools to generate an example project so there are no additional complexities that would make it harder to follow.
3. Your changes are persisted to the session which will be flushed automatically to the DB by Hibernate, but in most cases the runtime is much faster than the session time out. So the code isn't wrong for long-running apps, just in the context of this super-simple application, it could benefit from transactions.
4. The workaround we provided (http://www.myeclipseide.com/index.php?name=PNphpBB2&file=viewtopic&p=88206#88206) completely rewrites the generated code by hand to force transaction boundries into the atomic save/update/remove operations just to make the example work better, but that doesn't make the code any more correct.

Now, that being said, for folks that only need the atomicly-scoped transactions, I think we could probably enhance the tools to add a checkbox during rev-eng to generate micro-scoped transactions around the add/remove/update operations. For folks that are doing larger-scale apps and need wider scoped transactions, they could skip that step and code them in themselves.

Sorry for the confusion and frustration, I think this is a shortcoming of the tutorial itself explaining this step and not so much the code.

support-rkalla wrote:

Guys, the reason this was never changed in the tutorial is because it's not a bug, it's just a conflict of applicability and actually exposes an opportunity for an enhancement here. Let me explain: 1. Our rev-eng tools never generate transaction boundries, because we have no idea what they are. That's design/application dependent. 2. The tutorial uses our straight rev-eng tools to generate an example project so there are no additional complexities that would make it harder to follow. 3. Your changes are persisted to the session which will be flushed automatically to the DB by Hibernate, but in most cases the runtime is much faster than the session time out. So the code isn't wrong for long-running apps, just in the context of this super-simple application, it could benefit from transactions. 4. The workaround we provided (http://www.myeclipseide.com/index.php?name=PNphpBB2&file=viewtopic&p=88206#88206) completely rewrites the generated code by hand to force transaction boundries into the atomic save/update/remove operations just to make the example work better, but that doesn't make the code any more correct. Now, that being said, for folks that only need the atomicly-scoped transactions, I think we could probably enhance the tools to add a checkbox during rev-eng to generate micro-scoped transactions around the add/remove/update operations. For folks that are doing larger-scale apps and need wider scoped transactions, they could skip that step and code them in themselves. Sorry for the confusion and frustration, I think this is a shortcoming of the tutorial itself explaining this step and not so much the code.

Agreed it may not be a bug, but I spent more than a day and wrecking the application to find out why my objects do not save.
The tutorial should mention this explicitly that for some DB like Oracle do not do auto-commit and you would need to set <property name="connection.autocommit">true</property>

Can you provide examples of how to use transacations with Spring,Hibernate and annotations?

Also in future reverse engineering, could you also create sample named queries, criteria and JUnit (with mock test cases)
Ideally it would be nice if we can also generate sample web-app based upon the DAOs. This would create a complete web app like Skyway Visual Perspectives.

Thanks

Thank you for the enhancement suggestion. We will certainly take your suggestions into consideration for future persistence docs to clarify some of these points.