Updating functionality has been added to ResourceServiceREST. All data associated to a resource can be updated with the exception of the calendar field, since the updating semantics are only clearly defined for such field at this moment (what happens with the previous derived calendar: modified?, removed?, disabled?).
As part of this patch, some improvements to CriterionServiceREST implementation have also been made. In particular, updateUnvalidated methods has been added to related entities (as in ResourceServiceREST). Unlike createUnvalidated methods, such methods are used for updating, and like createUnvalidated methods, non-valid fields are allowed.
Finally, performance of GenericRESTService has been improved. Previously, validations were executed twice for each entity being imported due to previous limitations of IGenericDAO interface. Now, a new method has been added to IGenericDAO to make possible to execute validations only one time for each entity being imported.
ResourceServiceREST has been adapted to GenericRESTService. Updating functionality in ResourceServiceREST is not implemented yet.
As part of this patch, the generic infraestructure for REST services has been improved. In particular, recoverable error support has been provided. Exceptions representing recoverable errors must extend from RecoverableErrorException. To demonstrate this capability, ResourceServiceREST nows reports non-existent calendars, criterions, critetion types, and cost categories as recoverable errors.
IMPORTANT: "code" column has been added to tables of the following entitites: Resource, CriterionSatisfaction, and ResourcesCostCategoryAssignment. "code" column has been removed from Machine's table. In consequence, it is better to remove all the database when applying this patch (navaldev, navaldevtest, navalprod, and navaprodtest).
This change is compatible with the current Web user interface. The only thing you will notice is that when creating a machine, the form containing the code automatically displays a value in the code field (which, of course, can be changed by the user). Of course, the user interface should be improved to set a blank value or propose a more meaningful code to the user (probably this second option).
The service has not been adpated to GenericRESTService yet and duplicate codes in resources *being* imported are not detected yet (GenericRESTService will make this automatically).
It illustrates an error when trying to add a resource with overlapping criterions satisfactions refering to the same criterion (even though its criterion type allows simultaneous criterion satisfactions). This case was already illustrated as a test case in ResourceServiceTest.
Please note that criterion satisfaction overlapping means: (1) if criterion satisfactions refer to the same Criterion, they must not overlap (regardless of its CriterionType allows simultaneous criterion satisfactions per resource), and (2) if CriterionType does not allow simultaneous criterion satisfactions per resource, criterion satisfactions (of the same type) must not overlap (regardless of they refer to different Criterion objects).
Support for importing resources with cost assignments has been implemented. Many test cases have been implemented for checking all constraint violations in cost assigments (special care has been taken to check time interval overlappings). toString method has been implemented in constraint violation related DTOs to facilitate debuging in testing.
Resources to be imported can now specify a calendar name. Each resource will have a derived calendar of the specified one. Furthermore, test cases have been implemented for the most common cases (calendar not specified -> use default calendar, calendar specified, and non-existent calendar).
Resources with the same "logical" name (code for machines; first name, surnamne, and nif for workers) among the list of resources *being imported* are detected. This detection must be implemented at the service-level (at the entity-level, @AssertTrue annotations in Machine and Worker detect importation of resources with the same logical name as other resources already existing in the *database*). A test case has been added (furthermore, ResourceServiceTest has been refactorized a little bit).
--
Fernando Bellas Permuy
Associate Professor (Titular) at University of A Coruña
Department of Information and Communications Technologies
Facultad de Informática - Campus de Elviña, S/N
15071 - A Coruña - Spain
http://www.tic.udc.es/~fbellas - fbellas@udc.es
Tel: +34 981 167 000 (ext: 1353) - Fax: +34 981 167 160
>From c9af4778e28e370fb2a8dc2c63a4d75e41a07d7f Mon Sep 17 00:00:00 2001
From: Fernando Bellas Permuy <fbellas@udc.es>
Date: Thu, 31 Dec 2009 13:14:28 +0100
Subject: [PATCH 6/7] ItEr41S15CUImportacionRecursosProductivosItEr40S20: Constraint added to verify criterion satisfactions are of a CriterionType compatible with the resource.
A test case has also been added.
@Valid has been specified in Resource::getCriterionSatisfactions. A test case has been added to verify a validation constraint is generated when a resource containing a criterion satisfaction without start date is being imported with the REST service (@Valid annotation is necessary).
Bug fixed when firstName, surname or nif are null in a worker to be imported with the REST service. Now, Worker::checkConstraintUniqueFirstName checks if such fields are null.
REST service for importing resources has been exported remotely. A script and a sample file with resources is also provided. Complex validations are not implemented yet.
