Что такое общие антишаблоны использования Мерзавца? [закрытый]
Невозможно сделать это в одном запросе. Вы должны искать документ в первом запросе:
Если существует документ:
db.bar.update( {user_id : 123456 , "items.item_name" : "my_item_two" } ,
{$inc : {"items.$.price" : 1} } ,
false ,
true);
Else
db.bar.update( {user_id : 123456 } ,
{$addToSet : {"items" : {'item_name' : "my_item_two" , 'price' : 1 }} } ,
false ,
true);
Не нужно добавлять условие {$ne : "my_item_two" } .
Также в многопоточной среде вы должны быть осторожны, чтобы только один поток мог выполнить второй (вставить регистр, если документ не был найден) за раз, в противном случае будут вставлены дублирующие вложенные документы.
5 ответов
Это более общее, чем специфическое для git, но я видел много проектов с сообщениями коммитов типа «bugfix», «fix foo» или «stuff». Не делайте этого, вместо этого используйте осмысленные коммит-сообщения, такие как «component fiz: Fix foo bug [\ n \ nExtra info]» и «Очистка пробелов». Вы будете благодарить себя, когда позже неизбежно посмотрите на свою историю коммитов, и вам не нужно будет говорить «Что, черт возьми, я имел в виду, когда совершал« вещи »?»
Не используется git stash
Сценарий: вы работаете над функцией A. У вас ушло около 2 дней, и у вас есть примерно один день для ее завершения. Вы написали хороший код, но это еще не все. Появляется ваш начальник и говорит: «Эй, мне сейчас нужна функция B. Должно занять 10 секунд».
Конечно - 10 секунд, чтобы написать ее, 2 дня работы потеряны. Или 2 часа, пытаясь закомментировать и взломать весь код, который вы написали за последние 2 дня, чтобы вернуть все в рабочее состояние.
git stash здесь, чтобы спасти день. Просто введите git stash в командной строке, в корне вашего проекта, и все ваши последние изменения перейдут в «stash», который представляет собой стек изменений. Теперь вы вернулись туда, где вы были 2 дня назад, но ваша работа не потеряна. Вы вносите 10-секундное изменение, регистрируете его, затем набираете git stash pop, чтобы вернуть ваши изменения (и удалить их из стека).
Как может быть очевидно, если у вас ужасный день, вы можете копить несколько раз, хотя, очевидно, чем больше вы это делаете, тем менее веселым может быть слияние, когда вы, наконец, сделаете git stash и выбросите их все. Если вам удастся накопить много тайников за месяцы работы, у вас есть git stash list, чтобы просмотреть их, git stash pop и git stash drop, чтобы выбрать, какие из них стоит вернуть, а какие лучше просто бросить, и git stash clear если только ты прячешь ужасные идеи.
Перенос одного большого репозитория из SVN и т. Д. В один большой репозиторий Git является явным препятствием. Способ git разработан, вы не можете делать частичные проверки, и даже фиксация может быть медленной. Лучше модульно использовать репо для каждого компонента. По крайней мере, репо на команду. Определенно не репо в организации.
Большой шар изменений
Когда вы пишете сообщение о фиксации и не знаете, что поместить в однострочную сводку изменений, это, вероятно, означает, что вы поместили слишком много независимых вещи в одном коммите. Лучше разделить коммит на меньшие, используя « git rebase --interactive » и / или « git add --interactive » и друзей (например, « git stash - keep-index "для проверки сохраненных изменений).
Наличие единственной проблемы для каждой фиксации очень поможет при попытке найти ошибку с помощью" git bisect ".
Как человек, который много пользовался SVN, прежде чем недавно начал использовать Git все больше и больше, могу сказать, что моя худшая привычка - делать git commit, git push, git commit, git push, git commit, git push. ..
Другими словами, всегда толкаю после каждого коммита, как будто я все еще использую SVN.
После первоначального обучения, необходимого для отказа от этой привычки, мой рабочий процесс стал намного быстрее. Одним из встроенных преимуществ Git'а является тот факт, что локальная фиксация намного быстрее, чем удалённая. Другое преимущество заключается в том, что если не делать почти постоянные удалённые коммиты, то, скорее всего, впоследствии вам не оттяпают ногу (особенно если это маленькая команда, даже если это большая команда).
Для меня здесь нет реальной аналогии SVN (которая не вызывает антипаттерн Якуба Наренбски "большой шар изменений").