Code review comment for lp:~lamont/maas/bug-1567176

The crux of the issue here is that if postgres is enforcing unique=True on name, then (since many things are not done inside of transactions), then default names become a source of conflict (the default name relies on the id, which is not known until the commit succeeds, and multiple branches can be in the middle of the insert-and-update logic at the same time.)

Making everything that inserts a space or fabric be transactional would be a solution, but I believe it's an invasive one to consider.

If we don't have the database enforce uniqueness, then we get near-uniqueness from the very sorts of situations that we run into above (where two inserts of spaces _with_ names that are the same, happen to pass in the night and both succeed.) TBF, this is an extremely unlikely case. If we do hit it, then we have the situation where two users create spaces (with the same name), and then whoever updates next fails, even though they didn't change the name....