1

Topic: REST and JPA, the form of editing of several entities

Whether there is any settled approach to usage JPA in such context? * on UI there is any form in which the operator edits well for example the information on the driver and its motor vehicles (which can be a little). * This form is sent by one request on  at which the driver is one essence, and the motor vehicle - another, and  transforms accordingly sent request into entity set changes. I will start with here that that motor vehicles in itself interest nobody and are only a part of the information on the driver. It is normal not so, but for an example descends. Here I represent what variants to myself. 1. The form is sent as the list of changes, that is UI  what actions of the operator added new machines what deleted available what changed the available. Sends this list of changes  (here question how to identify earlier existing entities, most likely at show of the form front took at  their identifiers and now them sends reversely). In this variant the client explicitly informs , with what essence what to do. 2. The form is sent as the total version of the data - for example any JSON, consisting of the driver in whom it is enclosed its collections of machines. Thus  transits on a collection and if for essence it is specified id - that updates it if it is not specified - creates new if any id is not present and in a DB now such machine is connected to the driver - deletes it. 3. Similarly previous, but instead of pass manually under the sent object list and that determination that it is necessary to make with each essence, sent JSON turns to the graph created through new (or  from JSON even) entities, some of which have identifiers. For example there is new Driver and at it collection Vehicles in which forms new Vehicle for everyone enumerated in JSON machines. Then it is used em.merge to it Driver, and it, including these entities detached, defines, what operations need to be fulfilled. My question while at all about that that from this correct or wrong. Who is interesting to me as does of people who with JPA works for a long time already. Slicer

2

Re: REST and JPA, the form of editing of several entities

Hello, Slicer [Mirkwood], you wrote: SM> who is interesting To me as does of people who with JPA works for a long time already. Greetings. We do approximately so - we admit is certain rest api which gives and accepts for update of the driver and its cars in a format json - are a layer of entities of model which  on basis. We will name them entity - there is a layer of entities of model, which  on json. We will name them view object (or in abbreviated form vo) it is very frequent vo-shki it is very similar on entity, but can and differ a little. For example can contain less than fields if for representation this field is not necessary. We admit now the request about saving of the driver came. - in the controler json automatically  on vo-shki so in application we can already work with objects. To a word in spring,  entities on json and reversely becomes automatically. The controler also can fulfill basic , for example that the field was not null and . Further - the controler causes service, and transfers there vo. - in service:  these vo-shki on entity (manually or using high-level  like: dozer or java-object-merger). -  with already existing in basis.  between entities it is found on id-shnikam. In service there can be more difficult  . If, what not so - we throw an exception which is then intercepted in global  exceptions and it will be transformed in  the answer to the client. - further we cause methods entity manager to save changes (persist, merge).

3

Re: REST and JPA, the form of editing of several entities

Hello, GreenTea, you wrote: GT> -  with already existing in basis.  between entities it is found on id-shnikam. GT> - further we cause methods entity manager to save changes (persist, merge). Here this part can be specified? "" but by explicit decision-making persist or merge for each essence? Type, if isNew that persist differently merge? If so it is the second method described by me, in essence? With some intermediate steps. Slicer

4

Re: REST and JPA, the form of editing of several entities

Hello, Slicer [Mirkwood], you wrote: SM> Hello, GreenTea, you wrote: GT>> -  with already existing in basis.  between entities it is found on id-shnikam. GT>> - further we cause methods entity manager to save changes (persist, merge). SM> Here this part can be specified?"  "but by explicit decision-making persist or merge for each essence? Type, if isNew that persist differently merge? If so it is the second method described by me, in essence? With some intermediate steps. SM> Slicer yes if id == null then it is new essence and it is necessary to make persist. Generally, if at you it is used Hibernate as JPA the provider it is not is mandatory admissible at car adding to save it in an explicit form causing persist. It is Enough to add of it in a collection of cars of the driver. And further  itself  that the collection of objects changed, finds new objects and adds them. And if exchanged already  also defines these changes and updates in basis.

5

Re: REST and JPA, the form of editing of several entities

I in shock - what not so with my question if nobody wishes anything to answer here, on stack? I already simply ask to tell who as does, instead of to give me the ultimate truth. But is not present. And even the text any more so much as was in the first variants of a question smile

6

Re: REST and JPA, the form of editing of several entities

Hello, GreenTea, you wrote: GT> Yes if id == null then it is new essence and it is necessary to make persist. GT> Generally if at you it is used Hibernate as JPA the provider it is not is mandatory admissible at car adding to save it in an explicit form causing persist. It is Enough to add of it in a collection of cars of the driver. And further  itself  that the collection of objects changed, finds new objects and adds them. And if exchanged already  also defines these changes and updates in basis.  if cascading is included. And it not a singularity hibernate, it is provided  JPA - cascading  or . So it is possible to go further away and to come to the third variant from enumerated by me - to make all one call merge, beforehand preparing the graph of entities. But there are also some problems with this approach. About it I separately will get talk, to me at first this point in question to close smile Slicer

7

Re: REST and JPA, the form of editing of several entities

8

Re: REST and JPA, the form of editing of several entities

9

Re: REST and JPA, the form of editing of several entities

10

Re: REST and JPA, the form of editing of several entities

11

Re: REST and JPA, the form of editing of several entities

For reception of the data from REST the separate classes similar are used, but is not mandatory on 100 %, on classes,  in a DB. In remaining the variant 2 if is id old record if is not present id new if did not come it deleted, then from basis the driver with machines is pulled out and is manually modified the list of its machines according to the sent data (udaljaetsja/dobavljaetsja/is modified), well and is saved then.