[PATCH 1 of 4 RFC] hook: have a generic hook for transaction opening

Ryan McElroy rm at fb.com
Wed Mar 11 11:17:27 CDT 2015


On 3/10/2015 9:15 AM, Pierre-Yves David wrote:
>
>
> On 03/10/2015 06:04 AM, Augie Fackler wrote:
>> On Tue, Mar 10, 2015 at 01:14:28AM -0700, Pierre-Yves David wrote:
>>> This is RFC because I'm unhappy with the current names, but they are 
>>> going
>>> to be bikesheded anyway. So I would like to get the topic moving and 
>>> code is
>>> a good way to get that.
>>>
>>> The name in this series are:
>>>
>>> - txnopen (can abort)
>>> - txnclosing (can abort)
>>> - txnclosed
>>
>> I have no particular recommendations for better names (sorry), but I'm
>> not sure what the merit of txnopen is given that we can't provide much
>> information. A sample use case would help there, I guess.
>
> I've no sample usecase for txnopen, but it is very cheap to add and I 
> guess some extension//baroque setup will be very happy to have some 
> official way to control//record transaction opening.
>
> We could also move it a bit further to right after the transaction 
> have been openened (or add a new hooks for that). So that its easy to 
> add data in the transaction after it is open.
>
> Maybe we should have a hook for aborted transaction too. But yet again 
> I've no specific usecase in mind.
>
>> As for the others, we could probably rework some existing
>> functionality to be examples. verify-after-push could be done as a
>> txnclosing, and txnclosed could be used by the notify extension, so I
>> see merit in both of those.
>
> txnclosing and txnclosed are -must-have-. None of the current hook 
> allow to catch a full transaction run with all its data. This is 
> extremely annoying for validation or synchronization.
>
The only idea I have on naming is "trx" instead of "txn", which is what 
I remember using back in my MySQL days. This is purely bikeshedding, and 
I feel bad about it, but you did ask... sooo...

I prefer the "optimal" version you suggested with trx:

- pretrxopen
- pretrxclose
- trxclosed

That being said, the functionality here matters more than naming, and I 
don't think any of the names proposed so far would be hard to understand 
what is going on.


More information about the Mercurial-devel mailing list