From a cursory look it seems fine to me, does not add new files so there is no need
for a contribution agreement, but wanted to run it by the list before merging as it represents
a catalog api change (it’s an otherwise small one, I don’t believe there’s a need
for a GSIP, but if you do please say so)
I may be out of the loop, I thought the idea was to store extra stuff in the metadata map as required (so that the object relational mapping for a hibernate catalog would not have a moving target to track).
The patch itself seems straight forward.
–
Jody Garnett
On Saturday, 24 August 2013 at 7:59 PM, Andrea Aime wrote:
From a cursory look it seems fine to me, does not add new files so there is no need
for a contribution agreement, but wanted to run it by the list before merging as it represents
a catalog api change (it’s an otherwise small one, I don’t believe there’s a need
for a GSIP, but if you do please say so)
On Sat, Aug 24, 2013 at 3:48 PM, Jody Garnett <jody.garnett@anonymised.com>wrote:
I may be out of the loop, I thought the idea was to store extra stuff in
the metadata map as required (so that the object relational mapping for a
hibernate catalog would not have a moving target to track).
Normally we use metadata only when backporting to the stable series, but
keep new fields for trunk.
The hibernate persistence module is dead, afaik the current jdbcconfig
module stores xml blobs in the
database (so, it uses xstream just like disk config and rest)
I may be out of the loop, I thought the idea was to store extra stuff in the metadata map as required (so that the object relational mapping for a hibernate catalog would not have a moving target to track).
Normally we use metadata only when backporting to the stable series, but keep new fields for trunk.
The hibernate persistence module is dead, afaik the current jdbcconfig module stores xml blobs in the
database (so, it uses xstream just like disk config and rest)
I may be out of the loop, I thought the idea was to store extra stuff in the metadata map as required (so that the object relational mapping for a hibernate catalog would not have a moving target to track).
Normally we use metadata only when backporting to the stable series, but keep new fields for trunk.
The hibernate persistence module is dead, afaik the current jdbcconfig module stores xml blobs in the
database (so, it uses xstream just like disk config and rest)
On Mon, Aug 26, 2013 at 6:54 PM, Gabriel Roldan <groldan@anonymised.com> wrote:
+1 for merging the pull request.
Nice, it seems there is good agreement.
The earliest I can try to build with the patch and try it interactively
before a merge is
next weekend, if someone wants to do that before me and merge, well, it
would be appreciated :-p