[dev] Re: whups: Batch changes on tickets

[Jan Schneider]

Zitat von Auke Bruinsma <air2 at dds.nl>:

> As pointed out in ticket 1612 (http://bugs.horde.org/ticket/?id=1612)
> some batch execution should be handy. So I am thinking about the best
> approach of implementing such a feature. My approach would be to make a
> new object (Whups_Batch) when its created an array of tickets must be
> provided. The object has multple actions, like: Move, Change (this
> includes assign, comment, new queue etc.), Delete, Commit.

This sounds like a nice, abstract solution, but wouldn't it be much 
easier to change the existing methods that currently update tickets and 
accept a single ticket ID, to also accept an array of IDs?

> Maybe the Move already includes delete (move to nowhere) but the
> downside of this is, that it is not possible to check for accedently
> empty destinations. So I think there should be a protected _move and a
> Move and Delete who both call this _move. But if Delete is totally
> different from move, they must be seperated.
> But Move is also included in Change, so maybe just make only a Change
> implementation. Or make functions that call the change implementation.
> Like done in the Ticket class.

This should be left to the concrete driver implementation. The only 
driver we currently have, the SQL driver, would need different methods 
for moving and deleting. Actually you shouldn't need to care about that 
at all, because however you implement the batch "container", you would 
still call the exiting methods for single tickets and don't have to 
care about their implementations.

> All the actions should optionally supplied with the ticket array. If
> none is given, the one given when the Batch class was created should be
> used. If none is given an error should be raised.

Huh?

> Another approach is not to supply the ticket array, but the query that
> generated the ticket array. After every chnage the query could
> optionally be executed again, to re-evalute the results and continue to
> working on the new set of tickets. (But how to handle when a ticket is
> added, between the first query execute and the second) So the query
> should only execute on the array generated by the last query execute in
> that batch class.

That's a bad idea, unpredictable behaviour is inevitable with such a solution.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/