[
https://issues.apache.org/jira/browse/HIVE-10562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sushanth Sowmyan updated HIVE-10562:
------------------------------------
Attachment: HIVE-10562.patch
Attaching patch. In this patch, I've chosen to do a couple of things:
a) The extra field is called "fmt" for format, rather than a version number,
since it is more useful to encode the format and version number together as 1
entity, since they are really two sides of the same coin.
b) I've bumped up the size of the message field in mysql and derby, since the
current limits were pretty limiting for some of the larger messages we'll now
be seeing, now that we're encoding the respective objects into them as well.
> Add version column to NOTIFICATION_LOG table and DbNotificationListener
> -----------------------------------------------------------------------
>
> Key: HIVE-10562
> URL: https://issues.apache.org/jira/browse/HIVE-10562
> Project: Hive
> Issue Type: Sub-task
> Components: Import/Export
> Affects Versions: 1.2.0
> Reporter: Sushanth Sowmyan
> Assignee: Sushanth Sowmyan
> Attachments: HIVE-10562.patch
>
>
> Currently, we have a JSON encoded message being stored in the
> NOTIFICATION_LOG table.
> If we want to be future proof, we need to allow for versioning of this
> message, since we might change what gets stored in the message. A prime
> example of what we'd want to change is as in HIVE-10393.
> MessageFactory already has stubs to allow for versioning of messages, and we
> could expand on this further in the future. NotificationListener currently
> encodes the message version into the header for the JMS message it sends,
> which seems to be the right place for a message version (instead of being
> contained in the message, for eg.).
> So, we should have a similar ability for DbEventListener as well, and the
> place this makes the most sense is to and add a version column to the
> NOTIFICATION_LOG table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
