Что сделать с несколькими проектами в зависимости от того же источника?
Поскольку вы храните идентификаторы сообществ, убедитесь, что идентификаторы не проанализированы. Для этого communities должно быть типа keyword. Во-вторых, вы хотите сохранить массив идентификаторов сообществ, поскольку пользователь может принадлежать нескольким сообществам. Для этого вам не нужно делать его типа nested. Вложенный имеет все вместе разные варианты использования. Для хранения значений в виде массива необходимо убедиться, что при индексации вы всегда передаете значения в поле как массив, даже если это одно значение.
Вам нужно изменить отображение и способ индексации значений по полю communities.
PUT my_index
{
"mappings": {
"_doc": {
"properties": {
"amazonId": {
"type": "text"
},
"title": {
"type": "text"
},
"subtitle": {
"type": "text"
},
"description": {
"type": "text"
},
"createdAt": {
"type": "date"
},
"updatedAt": {
"type": "date"
},
"published": {
"type": "boolean"
},
"communities": {
"type": "keyword"
}
}
}
}
}
PUT my_index/_doc/1
{
"title": "The One True Document",
"communities": [
"edd05cd0-0a49-4676-86f4-2db913235371",
"672916cf-ee32-4bed-a60f-9a7c08dba04b"
]
}
GET my_index/_doc/_search
{
"query": {
"bool": {
"filter": [
{
"term": {
"communities": "672916cf-ee32-4bed-a60f-9a7c08dba04b"
}
}
]
}
}
}
Подход Nested Field
1. Картирование:PUT my_index_2
{
"mappings": {
"_doc": {
"properties": {
"amazonId": {
"type": "text"
},
"title": {
"type": "text"
},
"subtitle": {
"type": "text"
},
"description": {
"type": "text"
},
"createdAt": {
"type": "date"
},
"updatedAt": {
"type": "date"
},
"published": {
"type": "boolean"
},
"communities": {
"type": "nested"
}
}
}
}
}
PUT my_index_2/_doc/1
{
"title": "The One True Document",
"communities": [
{
"id": "edd05cd0-0a49-4676-86f4-2db913235371"
},
{
"id": "672916cf-ee32-4bed-a60f-9a7c08dba04b"
}
]
}
GET my_index_2/_doc/_search
{
"query": {
"bool": {
"filter": [
{
"nested": {
"path": "communities",
"query": {
"term": {
"communities.id.keyword": "672916cf-ee32-4bed-a60f-9a7c08dba04b"
}
}
}
}
]
}
}
}
Вы можете заметить, что я использовал communities.id.keyword, а не communities.id. Чтобы понять причину этого, пройдите это .
5 ответов
Мы использовали svn:externals указывая на общий код на практике в течение нескольких лет теперь. У нас были некоторые интересные проблемы с ним, что необходимо, вероятно, рассмотреть перед использованием его все же. Вот структура, которую мы имеем:
root
+---common
| +---lib1
| | \---trunk
| | +---include
| | \---src
| \---lib2
| \---trunk
| +---include
| \---src
+---proj1
| \---trunk
| +---include
| | \---common
| \---src
| \---common
\---proj2
\---trunk
+---include
| \---common
\---src
\---common
common каталоги в обоих include и src в проекте содержат внешние определения, которые вытягивают в общих библиотеках:
c:\dev> svn pget -v svn:externals proj1\trunk\src\common
Properties on 'c:\dev\proj1\trunk\src\common':
svn:externals : lib1 http://.../common/lib1/trunk/src
lib2 http://.../common/lib2/trunk/src
Проблема, с которой мы столкнулись, является многоаспектной, но связанной с метками и ветвлением наш источник, когда проекты изменяются в течение времени. Определение внешнего облика, которое я показал выше, имеет несколько довольно серьезных проблем, если Вы хотите иметь восстанавливаемые сборки:
- Это относится к динамической цели -
trunk. - Это не относится к явному пересмотру.
Когда Вы переходите с помощью svn copy, внешний облик копируется дословно, так как они - действительно просто свойства, присоединенные к объекту. Некоторые из других команд svn (commit, checkout, и export) на самом деле интерпретируйте свойства. При метках проекта Вы действительно хотите сохранить состояние проекта навсегда. Это означает, что необходимо "прикрепить" внешний облик к определенному пересмотру, таким образом, необходимо измениться, определение внешнего облика явному относятся к пересмотру, который Вы хотите (например, "lib1 -r42 http://.../common/lib1/trunk/src"). Это решает один фасет проблемы.
Если необходимо поддержать несколько несовместимых ответвлений общего кода, то необходимо указать, какое ответвление Вы хотите явно наряду с (возможно) пересмотром.
Само собой разумеется, это может быть чем-то вроде головной боли. К счастью кто-то там на земле Подверсии пишет svncopy.pl сценарий, который автоматизирует часть этой путаницы. Мы все еще (и были), борющийся с некоторыми трудностями, поддерживающими, это в поле развернуло продукт с набором общего кода и мандата трех различных версий в поле в любое время.
Если Вы действительно спускаетесь по этому маршруту, то, несомненно, рассмотрите, как Вы поддержите связи, когда проекты растут и изменяются. Мы нашли, что определенное время, думая о процессе будет иметь большое значение здесь.
Поместите все совместно используемые файлы в отдельную папку или в одном из проектов или в отдельном. Затем используйте внешний облик для ссылки на ту папку. Смешивание файлов от различных мест в той же папке является плохой идеей.
Внешний облик, но действительно знающий об этой проблеме:
svn:externals позволит Вам вводить файлы на уровне каталога. Как:
Proj1\
File1
File2
Proj2\
File3
File4
Затем в Proj2 Вы можете svn:externals Proj1, и заканчиваться с:
Proj2\
Proj1\
File1
File2
File3
File4
Теперь, если Вы хотите иметь файлы из 2 проектов в 1 папке как:
Proj2\
File1 <- from Proj1
File2 <- from Proj1
File3
File4
Затем я не думаю поддержки SVN это.
Однако я работал с другими инструментами управления исходным кодом, которые позволили бы Вам "связать" единственный файл от одного проекта до другого где угодно, Вы хотите (Borland StarTeam в особенности).