Thats why i still figthing with my entities. I didnt know that undetached entites are read only, but this happen with list values because with any other values like string i could change it. Thats why i never have figure it this limitation until rigth now that i need to modify a list. El 20/10/2013 14:52, "Romain Manni-Bucau" <[email protected]> escribió:
> Unmanaged entities are almost read only > Le 20 oct. 2013 21:48, "José Luis Cetina" <[email protected]> a écrit : > > > Whats is not supported by openjpa? > > El 20/10/2013 14:22, "Romain Manni-Bucau" <[email protected]> > > escribió: > > > > > Openjpa clearly doesnt support today...and no Mark it can or not work > by > > > spec... > > > Le 20 oct. 2013 18:04, "José Luis Cetina" <[email protected]> a > > écrit : > > > > > > > Responses inline. > > > > > > > > El 20/10/2013 06:51, "Mark Struberg" <[email protected]> escribió: > > > > > > > > > > Romain, that's nowhere in the spec. Thus it must work. Really! > > > > > > > > If this is true, what im doing wrong? Or this is openjpa or tomee > > issue? > > > > > > > > > > > > > > The only thing which is specified to be immutable are lists > returned > > by > > > > query.getResultList. > > > > > That's the reason why you should not back a sortable h:dataTable > by a > > > > list you get from JPA directly. > > > > > All other stuff is perfectly mutable. > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > > > > > > > > > > > > > > > >________________________________ > > > > > > From: Romain Manni-Bucau <[email protected]> > > > > > >To: [email protected] > > > > > >Sent: Sunday, 20 October 2013, 10:00 > > > > > >Subject: Re: Entity cant be refreshed with new list values > > > > > > > > > > > > > > > > > >Not really. An entity handles a state which can prevent it. > Nothing > > > > > >mandates it to work > > > > > > > > > > > >Le 20 oct. 2013 09:50, "José Luis Cetina" <[email protected]> > a > > > > écrit > > > > : > > > > > > > > > > > >> What about using a detached entity?? The detached entity will > work > > > > like a > > > > > >> DTO? > > > > > >> > > > > > >> From Real World Java EE Patterns (Adam Biem) 2009 > > > > > >> Problem > > > > > >> The origin problem statement was: “You want to transfer multiple > > > data > > > > > >> elements over a tier” > > > > > >> ( > > > > > >> > > > > > >> > > > > > > > > > > > > > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html > > > > > >> ). > > > > > >> This particular problem was elegantly solved in Java EE 5 with > > > > detachment > > > > > >> of persistent entities. There is > > > > > >> no need for the introduction of another class just for > > transferring > > > > the > > > > > >> entities data. JPA entities can > > > > > >> implement a java.io.Serializable interface and be transferred > > > between > > > > > >> tiers, even remote ones. > > > > > >> CMP 2.x entities weren’t Serializable, the developer was forced > to > > > > copy > > > > > >> their states to a remotely > > > > > >> transferable structure—the Transfer Object. > > > > > >> > > > > > >> > > > > > >> > > > > > >> 2013/10/19 Howard W. Smith, Jr. <[email protected]> > > > > > >> > > > > > >> > responses below... > > > > > >> > > > > > > >> > On Sat, Oct 19, 2013 at 3:46 PM, Mark Struberg < > > [email protected] > > > > > > > > > >> wrote: > > > > > >> > > > > > > >> > > be careful with immediate=true. You get all sorts of nasty > > side > > > > > >> effects. > > > > > >> > > > > > > > >> > > see page 92 in > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > http://people.apache.org/~struberg/eesummit2013/Java%20EE%20Summit%20-%20pitfalls%20in%20EE.pdf > > > > > >> > > > > > > > >> > > > > > > > >> > I definitely agree and understand about immediate=true, and > > guess > > > > what, i > > > > > >> > found it very useful to disable validation as instructed on > page > > > 92 > > > > of > > > > > >> the > > > > > >> > PDF file. > > > > > >> > > > > > > >> > clarification of my use/understanding: > > > > > >> > > > > > > >> > i am 'not' using immediate=true, when i user is to select a > row > > on > > > > > >> > datatable, and then click commandbutton/link/menuitem, which > > does > > > a > > > > POST > > > > > >> of > > > > > >> > the selected row on the datatable, and bean uses the selected > > row > > > to > > > > > >> > prepare the UI for the next view that is 'rendered' via > > > > > >> > ui:include=#{bean.page}. see below and keep reading, please. > > > > > >> > > > > > > >> > <p:menuitem value="Add" icon="ui-icon ui-icon-circle-plus" > > > > > >> > > > > > > >> > > actionListener="#{pf_pointOfContactController.prepareCreate()}" > > > > > >> > > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> > > > > > >> > <p:menuitem value="Edit" icon="ui-icon ui-icon-pencil" > > > > > >> > > > > > > >> > actionListener="#{pf_pointOfContactController.prepareEdit()}" > > > > > >> > > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> > > > > > >> > <p:menuitem value="View" icon="ui-icon-folder-open" > > > > > >> > > > > > > >> > actionListener="#{pf_pointOfContactController.prepareView()}" > > > > > >> > > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> > > > > > >> > <p:separator/> > > > > > >> > <p:menuitem value="Copy to Ordered By" icon="ui-icon > > > > ui-icon-newwin" > > > > > >> > > > > > > >> > > > actionListener="#{pf_pointOfContactController.copySelectedRows()}" > > > > > >> > > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> > > > > > >> > <p:menuitem value="Delete" icon="ui-icon ui-icon-trash" > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > actionListener="#{pf_pointOfContactController.confirmDeleteSelectedRows()}" > > > > > >> > > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}"/> > > > > > >> > > > > > > >> > but, for a readonly page that has commandbutton/links to > render > > a > > > > new > > > > > >> view, > > > > > >> > based on the current @Entity that is held in the JSF > > > controller/bean > > > > > >> class, > > > > > >> > i use immediate=true without issue and I think it fits/meets > the > > > > > >> > occasion/requirement, because there is no need to do > validation > > > > phase or > > > > > >> > update model values. see below. :) > > > > > >> > > > > > > >> > <p:commandButton value="Browse" icon="ui-icon-search" > > > > > >> immediate="true" > > > > > >> > update="#{pf_pointOfContactController.getAjaxUpdate()}" > > > > > >> > > > > > > >> > > actionListener="#{pf_pointOfContactController.prepareList()}"/> > > > > > >> > <p:commandButton value="Delete" icon="ui-icon > ui-icon-trash" > > > > > >> > immediate="true" > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}" > > > > > >> > > > > > > >> > > > actionListener="#{pf_pointOfContactController.confirmDelete()}"/> > > > > > >> > <p:commandButton value="Edit" icon="ui-icon > ui-icon-pencil" > > > > > >> > immediate="true" > > > > update="#{pf_pointOfContactController.getAjaxUpdate()}" > > > > > >> > > > > > > >> > > actionListener="#{pf_pointOfContactController.prepareEdit()}"/> > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> > > ------------------------------------------------------------------- > > > > > >> *SCJA. José Luis Cetina* > > > > > >> > > ------------------------------------------------------------------- > > > > > >> > > > > > > > > > > > > > > > > > > > > > >
