Smalyshev added a comment.
> for multilingual, ElasticSearch supports nested fields (as done with coordinates) but those can be problematic, especially with large nestings. Exactly. I'm not sure hundred-item nested field would do well. What is the use case for multilingual fields? Maybe it's not as common and can be done via other fields. > I think we need generic interfaces, such as FieldDefinitions and Field, and then maybe it's okay to have more specific implementations for specific search engines Well, somebody will have to implement it. So if we need field for ElasticSearch, the knowledge about this should be either in CirrusSearch or in specific extension, which would then have to know about all search engines. I'd like to avoid that, at least as much as possible - i.e. if I have to give specific Cirrus-related hints in extension, ok - but at least I don't have to copy whole index mapping creation logic. If I can just give it a flag and have Cirrus translate a flag into full-blown config - that is preferable. > For Wikibase, I am experimenting with unnested fields for multilingual content, though then we have hundreds of unnested fields and not sure there is some point where it's too many? Since Elastic says nested field is separate document anyway (https://www.elastic.co/guide/en/elasticsearch/reference/2.3/nested.html towards the end) the question is what is better - having a lot of fields in the same doc or separate one. We'll need to check that. Maybe @dcausse can help with it? > ElasticSearch also supports dynamic templates (though disabled for Cirrus). Well, I'm not sure internally it makes any difference if it happens on index creation stage - we create index once, so if definition is huge it's not a problem. Runtime performance is what is the concern here. TASK DETAIL https://phabricator.wikimedia.org/T89733 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel, Smalyshev Cc: DannyH, hoo, Deskana, RobLa-WMF, Tgr, Yurik, dcausse, JanZerebecki, Smalyshev, matthiasmullie, aude, Ricordisamoa, Krenair, MZMcBride, bd808, brion, Manybubbles, Aklapper, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, GWicke, jayvdb, fbstj, Jackmcbarn, Mbch331, Jay8g, Ltrlg, Legoktm _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
