Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
JPAContainer: Problem with MasterDetailEditor
I've got the following problem:
I have a table with a one-to-many relation (Schedule => ScheduleItem) and a form in Vaadin which enables me to edit a Schedule and add and remove ScheduleItems. I use JPAContainer's FieldFactory to create the Schedule form which automatically creates a MasterDetailEditor for the ScheduleItems. I can add new items and save the schedule and it works. However, if I try to remove a ScheduleItem or edit an existing one and click Save (which executes form.commit()), nothing happens - no changes are persisted.
Do you have any idea what could be the reason?
Could you post how your Schedule and ScheduleItem classes have been built? That would help to check what is possibly going wrong.
The helper class used by the FieldFactory is rather generic, but it does counts on some attributes. I checked from a test app, and there OneToMany mapping had this kind of attributes. Without cascades updated referenced entities would need to be manually updated and the orphanRemovel=true removes entities that end up referring to no "master entity".
@OneToMany(mappedBy = "invoice", cascade=CascadeType.ALL, orphanRemoval=true)
BTW. Have you considered to use the ElementCollection annotation instead? I think that could suit for your case as well if you'd also change ScheduleItem to Embeddable (vs. Entity). You'd need less complex jpa parameters with that.
thanks a lot for your quick reply! I usually create my database with MySQL Workbench and then auto-generate the JPA parameters with Eclipse.
The mapping has been simply
@OneToMany(mappedBy = "schedule")
and changing it to
@OneToMany(mappedBy = "schedule", cascade = CascadeType.ALL, orphanRemoval = true)
has solved the problem. I should probably read up on JPA... I don't know it very well. I also don't understand why I need Cascade here... I thought that I'd need Cascsade to update the child entries when I update the parent entry... i.e. the delete cascade would delete all child entries (scheduleitems) when I delete the associated parent entry (schedule)... and the update cascade would update all child entries with the new schedule-id if I update the associated parent entry's schedule-id.
But in this case, the application should be updating the schedulitem directly... which does not involve any changes to the schedule. So I don't understand why there is any need for a cascade? :(