Сегодня я копался в геопространственной коллекции, когда заметил, что у меня несчастливое имя одного из столбцов в коллекции.
В мире mySQL изменение имени столбца довольно просто благодаря команде alter table .
Монго … не так много …
<BEGIN_UNRELATED_SIDE_RANT>
Документация Mongo обычно является первым местом, куда большинство из нас обращаются, когда мы ищем помощи в использовании нашей любимой базы данных noSQL.
Зачем?
Ну … потому что это обычно то, куда Google направляет нас, а также потому, что там не так много документации по этому вопросу для начала.
Документация на монго (10gen) довольно хорошая. Это, однако, не отлично. И я могу сформулировать причину почему.
Довольно легко идентифицировать документацию, написанную инженерами, в отличие от документации, написанной всеми остальными (на планете). И не из-за технического содержания или (ab) использования действительно большого и впечатляюще звучащего жаргона.
Нет — это потому, что большинство документов, созданных инженерами, пишутся с использованием голоса, основанного на решении, а не голоса, основанного на проблемах .
Подумайте об этом: когда мне нужно обратиться к man-странице за помощью, это потому, что у меня проблема . Если бы у меня было решение , я бы написал сообщение в блоге. Но поскольку у меня есть проблема , мне нужны справочные страницы, онлайн-документы, что угодно, чтобы помочь мне найти решение.
Инженерные документы написаны с точки зрения решения: в документе предполагается, что вы обладаете некоторой тайной историей (которая, вероятно, является именно той маленькой историей, которую вы упускаете, что вызвало вашу поездку в хранилище документации) и всем, что объясняется в этом документе все зависит от того знания, которое, как предполагает автор, хотя и с наивысшими намерениями, уже прочно находится в вашем умственном владении.
И именно поэтому мне обычно не нравится документация 10gen. Но, как я уже говорил ранее, это единственная игра в (Google) городе.
<END_UNRELATED_SIDE_RANT>
В mongo, чтобы изменить имя столбца в коллекции, вы должны сначала выпустить mongodb 1.7.2 или новее. Поскольку большинство из нас, передовых и ранних пользователей, имеют версии 2.x, это не должно быть проблемой.
Эта страница от 10Gen является страницей обновления, и в ней говорилось о модификаторе $ rename для команды update . В этом разделе ничего не сказано, поскольку предполагается, что вы хотите обновить записи, а не схему, а именно — как применить изменения ко всем записям в вашей коллекции.
В моем случае у меня есть имя столбца, которое я перепутал с именем «верблюд»: CountryID вместо countryID . (И, да, OCD-peeps, я знаю, что это не совсем camelCase, спасибо!) Я хочу прокрутить все 3,7 миллиона строк в моей коллекции и переименовать этот столбец …
> db.geodata_geo.update( {} , { $rename : { 'CountryID' : 'countryID' }}, true, true );
Итак, у нас есть команда обновления коллекции (geodata_geo) и четыре параметра:
- {} — пустой набор (это то, чего не хватает в 10gen документации), подразумевающий, что нужно делать что-либо с каждой записью в коллекции
- $ rename — модификатор команды обновления, который в данном случае заменяет ‘CountryID’ на ‘countryID’
- false — указывает, что разрешено использовать upserts, если запись не существует
- true — multi option: означает применить команду ко всем записям, так как по умолчанию update () завершает работу после обновления первой записи
И я запускаю эту команду, и монго выключается (whirr… whirr… у меня есть двухузловая репликация…) и переименовывает столбец в моей коллекции!
Чего он не сделал, так это обновил мой индекс.
Итак, после того, как мое переименование столбца завершилось, мне нужно было удалить индекс (ы), в которых в качестве членов использовался ‘CountryID’, и повторно проиндексировать коллекцию, чтобы отразить новое имя столбца.
Выполнение getIndexes () подтвердило, что мой мир монго вернулся на свою правильную орбиту, и жизнь снова была хорошей.
Источник: http://shallop.com/2012/01/renaming-mongodb-columns/