There is no need for any DB script changes. When the MS starts up, it reads all
the config depot exposed by manager beans and update the DB appropriately.
-Koushik
On 07/11/16, 5:28 PM, "Jeff Hair" <j...@greenqloud.com> wrote:
Hi,
That's what I thought was the case. Is there any particular process for
moving configs to the depot besides just moving it out of the enum and into
a manager bean somewhere? For example, would the pull request(s) need to
have a database migration of some kind?
Jeff
*Jeff Hair*
Technical Lead and Software Developer
Tel: (+354) 415 0200
j...@greenqloud.com
www.greenqloud.com
On Mon, Nov 7, 2016 at 11:15 AM, Koushik Das <koushik....@accelerite.com>
wrote:
> Config enum is legacy code. For any new configuration parameters
> ConfigDepot should be used. Some of the parameters got moved from Config
> enum to the appropriate manager classes (where it is getting used). But
> there are still lot of them left to be moved. Feel free to submit a PR for
> moving some of the config parameters to use ConfigDepot.
>
> -Koushik
>
> On 07/11/16, 4:31 PM, "Jeff Hair" <j...@greenqloud.com> wrote:
>
> Hi,
>
> What's the difference between the Config enum and the ConfigDepot? It
> seems
> like the configuration options are somwhat arbitrarily split between
> the
> two. ConfigDepot entries get created automatically, while ones in the
> Config enum don't (and thus require a database migration). ConfigDepot
> items are defined on classes, while the Config enum is of course one
> giant
> list.
>
> Is there a plan to eventually use only one or the other? Or are they
> going
> to be kept separate? Is there actually a use case for having both in
> the
> codebase?
>
> Jeff Hair
>
>
>
>
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read,
retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept
any
> liability for virus infected mails.
>
DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the
property of Accelerite, a Persistent Systems business. It is intended only for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient, you are not authorized to read, retain, copy, print,
distribute or use this message. If you have received this communication in
error, please notify the sender and delete all copies of this message.
Accelerite, a Persistent Systems business does not accept any liability for
virus infected mails.
