On 10/17/2013 10:43 AM, Thomas Segismont wrote:
Jay,
Le 17/10/2013 15:44, Jay Shaughnessy a écrit :
> The changes look thorough, I have a few comments:
>
> - I'm not sure about the Async change on the server service, maybe mazz
> can comment. But even if you lose the async calling I think you don't
> want to lose the guaranteed delivery. So you may want to consider (I
> think we allow this):
> @Asynchronous(value = false, guaranteedDelivery = true)
>
As Mazz said, this does not exist. Anyway synchronous calls guarantee
the delivery.
OK, sound like an ok change, then. Can you add a comment as to why it's
not async?
> - The check for isCreatable and then the subsequent name update code, I
> think this can go above the entityManager.persist(resource);. Very
> minor given everything else we do when merging a resource, but it could
> save an update if we change the name.
>
Right, I will update the changeset.
> - minor, just wondering why in findMatchingCreateResourceHistory() you
> create a query with order by, and not just a usual named query, avoiding
> all the pageControl/Ordering field stuff. There should only be at most
> one result as resource keys are unique among a parent.
#findMatchingCreateResourceHistory use the new
CreateResourceHistory.QUERY_FIND_BY_CHILD_RESOURCE_KEY named query.
PersistenceUtility#createQueryWithOrderBy is used because I did not
want to load all the entities from the database. There could be more
than one entity with the same parentId and resource key (if you
deleted then created again a resource).
Good point. I guess the query could be more specific by adding some
inventory status conditions but this approach should work fine.
Thomas
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel