> After all, batch queries are public and can
> be fired from anywhere, including context.performQuery(..).
Exactly, BatchQuery is just that - a query. And we probably do not
want to redefine how it is processed. So this leads me to think that
the logic fork should still happen somewhere inside
DataDomainFlushAction. You'd generate a BatchUpdateAction instead of
delete or something like that.
Andrus
On Jun 3, 2009, at 11:16 AM, Andrey Razumovsky wrote:
> 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:24:48 EDT