private schema changes

[shaheen]

i'm looking into making some private schema changes for our local deployment of gerrit to service some new workflows.  i'm wondering if there are any best practices for making private schema changes.  for instance, once we make ours and deploy the change, i'm thinking it's not possible to deploy a stock gerrit anymore.  also, assuming that our schema version is max+1, then our schema version will collide with the real public schema version space.

the best thing i can think of right now is to use a version number that's completely different, but still upgrade from the current schema version.  if newer gerrit schema changes come down later, i will have to change those schema to upgrade from my schema version.  which will be odd, since my schema version is something very large (e.g. 1000), and the new schema version is pretty small (e.g. 60).

will this work? is there a better way?

[Shawn Pearce]

I really don't know how to do this. Any time I have tried to fork the
schema by using e.g. schema version 100 things went badly during
upgrades. It just didn't work well.

Maybe instead of changing the schema, define a new one in the same
database. Instead of ReviewDb, define a new interface extending from
Schema that defines your own set of tables that are stored alongside
of the ones that Gerrit uses with ReviewDb? Then you need to bind a
SchemaFactory<YourType> in Guice and connect it to the same database
connection pool that the SchemaFactory<ReviewDb> uses.