It's not that easy as it sounds. BatchAction is born from BatchQuery (which
is in .query package and does not have access to DataDomain/Node) and
JDBCActionBuilder (which is logical part of JdbcAdapter, and also does not
have access to DataDomain/Node). After all, batch queries are public and can
be fired from anywhere, including context.performQuery(..). So it starts not
with DataDomainFlushAction, but with DataNodeQueryAction. The best I could
do was adding factory property to DataNode and passing it to action in query
observer.
2009/6/2 Andrus Adamchik <andru..bjectstyle.org>
> I swiched to DataMap after I saw no quick access to DataDomain in
>> BatchAction class.
>>
>
> It all starts with DataDomainFlushAction, which has a reference to DD, so
> there should be a way to inject factory down the tree.
>
> I assume API changes in public classes of access.jdbc package are allowed?
>>
>
> Until we are in Beta, yes.
>
> Andrus
>
>
>
> On Jun 2, 2009, at 5:25 PM, Andrey Razumovsky wrote:
>
> I swiched to DataMap after I saw no quick access to DataDomain in
>> BatchAction class. This needs futher investigation, we need to pass domain
>> there somehow. I assume API changes in public classes of access.jdbc
>> package
>> are allowed?
>>
>> 2009/6/2 Andrus Adamchik <andru..bjectstyle.org>
>>
>> Excellent. I have one comment (consistent with my position in the
>>> previous
>>> message). Configuration of the factory below should be attached to the
>>> stack
>>> objects (e.g. DataDomain), not the mapping objects (DataMap):
>>>
>>> +
>>> + /**
>>> + * Sets factory for creating QueryBuilders
>>> + */
>>> + public void setQueryBuilderFactory(BatchQueryBuilderFactory
>>> queryBuilderFactory) {
>>> + this.queryBuilderFactory = queryBuilderFactory;
>>> + }
>>> +
>>> + /**
>>> + *..eturn factory for creating QueryBuilders. Might be null
>>> + */
>>> + public BatchQueryBuilderFactory getQueryBuilderFactory() {
>>> + return queryBuilderFactory;
>>> + }
>>>
>>> Cheers,
>>> Andrus
>>>
>>> P.S. Maybe you can separately commit the..eprecated part of the patch
>>> ;-)
>>>
>>>
>>>
>>> On Jun 2, 2009, at 5:07 PM, Andrey Razumovsky wrote:
>>>
>>> For not to be unsubstantiated, I uploaded my vision of the feature. Note
>>>
>>>> that there is no modeler support. It allows to provide custom factory
>>>> that
>>>> creates builders of INSERT, UPDATE, DELETE queries. 'Soft-delete'
>>>> factory
>>>> is
>>>> included.
>>>> I do not say that 'soft delete' checkbox is not needed, but uploaded
>>>> code
>>>> is
>>>> much more generic and allows to plug any behavior (maybe even Ari's
>>>> proposed
>>>> 'versions'). 'Soft' strategy can be configured with 'deleted' field name
>>>> and
>>>> will not fire UPDATE if such field does not exist in DB table.
>>>>
>>>> Please add your comments!
>>>>
>>>> Thanks,
>>>> Andrey
>>>>
>>>> 2009/6/2 Andrus Adamchik <andru..bjectstyle.org>
>>>>
>>>>
>>>> On Jun 2, 2009, at 2:54 PM, Andrey Razumovsky wrote:
>>>>>
>>>>> But I'm no fan of adding some sort of 'soft' checkbox for dbattributes
>>>>>
>>>>>
>>>>>>
>>>>>> I was suggesting marking entity with a "soft delete" checkbox (not
>>>>> individual attribute - this would make no sense), and creating a
>>>>> criteria
>>>>> based on qualifier that references an attribute.
>>>>>
>>>>> Modeler support will be covered by setting class name of strategy
>>>>>
>>>>>
>>>>>>
>>>>>> I am afraid this approach will be rather arbitrary to the end user,
>>>>> so I
>>>>> suggest we discuss it some more before putting it in Cayenne. Marking
>>>>> an
>>>>> entity to use "soft delete" based on some criteria is a clear and
>>>>> understandable feature. Setting a "delete strategy" is not, and will
>>>>> contribute to confusion. This is totally be ok as a backend extension
>>>>> point,
>>>>> but I will hate to see that as a general use feature.
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
This archive was generated by hypermail 2.0.0 : Wed Jun 03 2009 - 04:16:35 EDT