Give RowsEvent a method to inspect the underlying event type.

[proton-lisandro-pin]

It's currently impossible to figure out what kind of operation led to a RowsEvent 😞
Multiple results indicate an UPDATE, but there's no way to differentiate an INSERT from a DELETE.

This PR implements a new method to determine the event type, regardless of version and/or engine.

[lance6716]

nit: It's better to add a separate type RowsEventType? Because I think the new methods of this PR can be used like

if e.IsInsert() {
  ...
} else if e.IsUpdate {
 ...
}
...

e.eventType will be checked for many times.

[lance6716]

Yes currently RowsEvent has no public type information. You can know the type from EventHeader

[proton-lisandro-pin]

Indeed. The problem is mostly that once casted to RowsEvent, it is impossible to inspect an event type - this unnecessarily complicates code needing to handle rows events based on operation type.
It also means consumers need to deal with raw event types (f.ex. UPDATE_ROWS_EVENTv01 vs UPDATE_ROWS_EVENTv2) which should be kept an implementation detail.

The type data is available thou, we just need to cleanly make it public.

[dveeden]

Does this work correctly with compressed binlog events in MySQL?

[proton-lisandro-pin]

nit: It's better to add a separate type RowsEventType? Because I think the new methods of this PR can be used like

Sure 😄 I was mostly following the existing style for Is*Column() methods for TableMapEvents, but i do like introducing a dedicated type better. Fixed.

[proton-lisandro-pin]

Does this work correctly with compressed binlog events in MySQL?

Not sure tbh. The change covers all binlog versions currently handled by the module, so if compressed binlogs are already supported, then yes.

[dveeden]

Does this work correctly with compressed binlog events in MySQL?

Not sure tbh. The change covers all binlog versions currently handled by the module, so if compressed binlogs are already supported, then yes.

These are in TransactionPayloadEvent, Not sure if and how that's handled. Might be good to test.

[proton-lisandro-pin]

These are in TransactionPayloadEvent, Not sure if and how that's handled. Might be good to test.

Ah, those a dedicated event type and won't be affected by this change then.

[lance6716]

For TransactionPayloadEvent, I see that it still holds sub-events like normal BinlogEvent

go-mysql/replication/transaction_payload_event.go

Lines 29 to 35 in 567aa59

	type TransactionPayloadEvent struct {
	format FormatDescriptionEvent
	Size uint64
	UncompressedSize uint64
	CompressionType uint64
	Payload []byte
	Events []*BinlogEvent

And the events are decoded like it's in a normal code path

go-mysql/replication/transaction_payload_event.go

Lines 144 to 148 in 567aa59

	pe, err := parser.Parse(data)
	if err != nil {
	return err
	}
	e.Events = append(e.Events, pe)

The problem is we didn't have a unit test to verify it, like capturing the wire data and decoding the TransactionPayloadEvent. I'll consider add such unit test later.