Seconded. Definitely +1 if you can do that migration in SQL. I think it's possible, but not easy. CTEs/With should help. But I wouldn't be -1 on (2) if you decide (1) isn't feasible.
On Thu, Sep 14, 2017 at 10:20 AM, Jan van Doorn <[email protected]> wrote: > The go migration is my fault…. I couldn’t figure out how to do some of > that stuff in SQL, and I think anyone would be hard pressed to do that. > > Wasn’t aware we need the go compiler for that when I went down that path > though. > > Maybe another alternative is to make a “light migration”? Here’s my > thinking - if I remember correctly most of that go code deals with the MSO > config moving from parameter overrides in header_rewrite to parent.config. > If you don’t have MSO, or are willing to migrate that stuff by hand, we can > create a simple SQL migration that just does the schema changes… > > I’ll be more careful pulling in something new like that next time, sorry… > > Cheers, > JvD > > > > On Sep 14, 2017, at 10:06 AM, Eric Friedrich (efriedri) < > [email protected]> wrote: > > > > As we’re moving to TC2.1, we’ve found that the goose migration requires > not just the goose binary to be installed, but also the go compiler and a > fairly large set of dependencies. Most of these are a result of the > migration of the MSO parent_retry parameters from the DS table into the > profile_parameters table. > > > > We have a very hard requirement that our product CANNOT require Internet > access for installation. > > > > We’d like to avoid vendoring (in one form or another) all of the goose > dependencies, the same way we’ve had to do with web-deps and CPAN. > > > > We are considering two solutions: > > 1) Replace the .go migration with a PL/SQL file that does not require > all of the go dependencies. In this case we would compile goose and ship it > as a binary in our RPM to eliminate the ‘go get goose' > > > > 2) Switch to a different fork of goose (https://github.com/pressly/goose) > that can execute binary migrations. Here we would compile the .go migration > into a binary and ship both the new goose binary and the migration binary > in our RPM. > > > > —Eric > > > > > >
