Confirmed this does indeed break existing installs relying on the default. What options do we have to work around this? Couple that come to mind might be:

• Add a new SQL patch that runs RENAME TABLE old_db.table_name TO new_db.table_name for every Phorge DB and table.
  • Con of this is that it may require a new GRANT ALL PRIVILEGES ON [...] statement based on how each install originally set things up (e.g., granting ON *.* versus ON phabricator%.*)
• Add a line in the release notes telling users to ./bin/config set storage.default-namespace phabricator if they're using the default namespace
  • Con of this is it's an out-of-band upgrade step that relies on instance maintainers reading the release notes and not setting and forgetting an upgrade script in a crontab on the assumption that stable generally is pretty stable
• Leave the default storage namespace as phabricator

One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change. I’m not suggesting we never consider it but it would be better if we can provide tooling/scripts where possible or even create a wider time span for migration. Would MySQL/MariaDB support aliases of some sort? Or maybe there’s a way we can support both namespaces for a time

One other option, if we're going to provide a migration guide, par of that could be setting the storage namespace... Brain fart and forgot that'll be something we do. But that'd let existing installs continue to use their Phab namespace and new ones the Phorge one

Alternatively, we could include a one-time migration step that sets the default storage namespace to the database as part of the storage upgrade step… this would ideally be silent.

One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change.

@speck is absolutely right and I would strongly recommend that we do not enforce any database migrations of this large magnitude on existing installs.

A change of this size would dis-incent migration to Phorge for some customers

Is this change necessary?

Is this change necessary?

It might be in the long term, but I guess the initial priority is to make it easy to update from phabricator to phorge: once most installs are relying on phorge I guess it will be easier to migrate.

@chris Option 3: when upgrading an existing instance, and *IF* the storage.default-namespace is not set explicitly, prompt the user.

This can actually be put in a install check for admin to see as a first step, just like when daemons are not running and other setup issue. Hey, please set storage.default-namespace explicitly.

I am not a fan of adding interaction to the upgrade process but we can use the "setup issues framework" or an approach similar to @deadalnix's comment.

@deadalnix's I like option 3 from a UX perspective - and it also lets us hold on this issue for a little while, without making things worse.

We can add set storage.default-namespace phorge for the instructions manual/scripts for new setups for the meanwhile.

Does anyone like, not like, or have additional thoughts on the general idea of making one or more unique identifiers that isn't "phorge", for the purpose of an identifier that is unmistakably greppable? I outlined some notes on this idea here: T15006#831

Once we add "phorge" everywhere, that string's going to get mixed into a multitude of different contexts and will be quickly difficult to extrapolate between contexts, just like "phabricator" is now... There could be a point where various unique identifiers can be changed *to* "phorge" if desired, but not the other direction

what about egrohp? ("phorge" backwards)?

I like the idea of having an easily greppeable token...

Leave the default storage namespace as phabricator

+1 for this..

For the case of email headers

In https://secure.phabricator.com/T13658#256009, @epriestley wrote:

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

Depending on how many of these we end up with, I think an email-header-prefix sort of config option might be reasonable.

It sounds like upstream is open to the idea of email headers being configurable to some extent. For email headers this is probably a better option than just changing the hardcoded value. I'm not sure whether this same approach makes sense for HTTP headers though.

Are there other identifiers aside from headers that would use this?