Send key information to the transaction log for inserts

[Marcus Eriksson]

In order to be able to auto-generate keys when replicating into a key-value store, it would help to have table key information in the insert header

[Jay Pipes (jaypipes)]

I mistook this to mean the name of the key, not all information about the key.

[Jay Pipes (jaypipes)]

Some relevant discussions from IRC:

<marcuse> jaypipes: insertrecord only contains repeated bytes insert_value = 1;
<jaypipes> marcuse: OK, now I know what the problem is...I thought you were referring to the name of the field. I believe you are referring to more information about the field, no? Like type, etc?
<marcuse> jaypipes: no, https://bugs.launchpad.net/bugs/493742
<jaypipes> marcuse: OK, so we should prolly throw this decision to the mailing list. Having full key information in all inserts may be a very large increase in the size of the trx log...
<jaypipes> marcuse: I'm thinking a better solution would be to open up an API for appliers/replicators to query for key/DDL information. Thoughts?
<marcuse> jaypipes: maybe i can pick up the DDL instead
<marcuse> jaypipes: all i need is the names of the key fields
<marcuse> i guess an api would work, but then the setup is not as simple (appliers not knowing at all where the updates are coming from)
<jaypipes> marcuse: hmmm....well the names of the inserted fields are in there...
<marcuse> jaypipes: yes, but i need to know whick the key fields are
<jaypipes> marcuse: right. currently, you'd have to have a cache of the create table statement messages...
<marcuse> jaypipes: now i have a config where the names of the key fields are listed, wanted to remove that
<jaypipes> marcuse: I will soon have the ALTER TABLE/SCHEMA as row-based messages in the trx log. They are the remaining RAW_SQL types...
<marcuse> jaypipes: that will rock, i guess i'll keep the config stuff until someone actually has a usecase for the nosql appliers
<jaypipes> marcuse: and with all row-based messages there would be no need to parse DDL SQL statements. A cache of the table/key definitions would be pretty trivial.
<jaypipes> marcuse: yes, I would do that.
<jaypipes> marcuse: I'm sure posulliv is also looking forward to no more RAW_SQL statements. Makes the filtered_replicator much easier to implement...

[Jay Pipes (jaypipes)]

Moving to Wishlist, as this isn't a bug, but rather an enhancement to the replication API...