criteria-based updates/deletes

Joseph Marques jmarques at redhat.com
Wed Nov 3 21:21:08 UTC 2010


I wasn't suggesting we do this immediately, just that it would be a 
useful direction to move in.  Regardless of when it gets done, the scope 
of this work is rather small (a few hours); given how useful it could 
be, its value tends to be on the high end.  So, depending on what other 
work gets rolled into 4.0 in the next few weeks (which I won't claim to 
know until it actually gets here), it may be something to consider.  
Keep in mind, not everyone has a full plate of GUI work.

On 11/03/2010 03:57 PM, Ian Springer wrote:
> I like the idea of adding support for criteria-based updates and 
> deletes, but I think it's something that can wait until after 4.0. We 
> already have our plates full with all the GUI work and other more 
> pressing stuff.
>
> On 11/02/2010 11:56 AM, Joseph Marques wrote:
>> On 11/02/2010 10:14 AM, Ian Springer wrote:
>>>     Yeah, I don't like it either. I was just trying to avoid API 
>>> changes.
>>> But since that method is only in the local interface, I guess I can add
>>> a new method, or methods, with less cryptic semantics, and then
>>> deprecate, or even just remove, this one.
>> The root issue here is that we're trying to weave a couple of difference
>> use cases into a very concise API:
>>
>> 1) enable the passed metric templates, setting their collection
>> intervals to the passed value
>> 2) enable the passed metric templates, keeping collection intervals to
>> their existing values
>> 3) disable the passed metric templates (which implies keeping collection
>> intervals to their existing values)
>>
>> Arguably, a user might also want to change the collection intervals
>> without affecting the enabled/disabled bit.  If so, both arguments types
>> would be optional, which makes using wrapper classes rather natural:
>>
>> MeasurementScheduleManagerBean {
>>      updateMeasurementDefinitions(..., Long collectionInterval, Boolean
>> enabled) {
>>         // if collectionInterval not-null, validate it, then include it
>> in the update-statement
>>         // if enabled not-null, include it in the update-statement
>>      }
>> }
>>
>> But that strategy has its own drawbacks:
>>
>> 1) several different permutations of the query need to exist (in this
>> case 4 difference versions, because each of the two arguments here can
>> be in 2 fundamentally different states [null or not null])
>> 2) a base query must exist, which is then (via string concatenation)
>> dynamically augmented/rewritten to account for non-null arguments
>>
>> -----
>>
>> I would like us to look into the possibility of using a criteria-based
>> solution here, whose mantra from day-1 has been the optionality of
>> arguments.  Something like:
>>
>> MeasurementDefinitionCriteria {
>>      List<Integer>  filterMeasurementDefinitionIds;
>>      ...
>>      other existing filters, which help narrow down the list of
>> definitions to update
>>      ...
>>
>>      // new part of the API
>>      Long updateCollectionInterval; // if non-null, set the
>> collectionInterval
>>      Boolean updateEnabled; // if non-null, override enabled/disabled 
>> bit
>> }
>>
>> Here, we've enhanced the criteria API to include new parameter types,
>> those with the naming convention "updateXXX".  If any of those are set,
>> then the CriteriaQueryGenerator will produce an update-statement
>> (instead of a select-statement), whose non-null "updateXXX" values
>> generate the list of fields to update on the corresponding entity.
>>
>> MeasurementScheduleManagerBean {
>>      int updateMeasurementDefinitionsByCriteria(subject, criteria) {
>>         // check authorization to ensure caller has permission to update
>> monitoring defaults
>>         CriteriaQueryGenerator generator = new
>> CriteriaQueryGenerator(subject, criteria);
>>         // potentially add authz fragments to the generated query, to
>> restrict the update list
>>         CriteriaQueryRunner<MeasurementDefinition>  queryRunner = null;
>>         queryRunner = new CriteriaQueryRunner(criteria, generator,
>> entityManager);
>>         return queryRunner.executeUpdate();
>>      }
>> }
>>
>> Notice that a new method would be added to the CriteriaQueryRunner
>> class, executeUpdate().  When the criteria object is not selecting
>> objects (requiring PageList<T>  to be returned) the executeUpdate()
>> method can be called which will return the count of affected rows 
>> instead.
>>
>> The benefit with this type of solution is that it enables users to
>> perform finely-tuned mass updates.  Now, the same Criteria object that
>> was able to flexibly find MeasurementDefinition objects (today you can
>> search for definitions by id, name, displayName, description,
>> resourceTypeName, resourceTypeId, measurementCategory, measurementUnits,
>> nmericType, dataType, displayType, enabledDisabled bit, and current
>> collectionInterval), and take what it finds and set new values for 
>> fields.
>>
>> So with just a little work at the CriteriaQueryGenerator and
>> CriteriaQueryRunner layers, we have a powerful solution that can be used
>> to deprecate a wide variety of existing methods across many of our 
>> SLSBs.
>>
>> Note: a criteria-based solution could use the same style to perform
>> deletes as well:
>>
>> SomeManagerBean {
>>      int deleteSomethingByCriteria(subject, criteria) {
>>         // check authorization to ensure caller has permission to delete
>> something
>>         CriteriaQueryGenerator generator = new
>> CriteriaQueryGenerator(subject, criteria);
>>         CriteriaQueryRunner<SomeThing>  queryRunner = null;
>>         queryRunner = new CriteriaQueryRunner(criteria, generator,
>> entityManager);
>>         return queryRunner.executeDelete();
>>      }
>> }
>>
>> Again, the benefit is that it exposes the familiar, fine-grained search
>> users got from the criteria filters...but now (instead of just returning
>> entities across the wire) the criteria framework can update and delete
>> stuff too.
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>
>



More information about the rhq-devel mailing list