Summary ======= The virtual database handler does not preserve the identity and description of the child dictionary when virtual databases are nested. A virtual database containing ordinary dictorg databases works correctly: when the same search term is found in several child dictionaries, the returned entries can be attributed to the corresponding individual dictionary. However, when a virtual database contains other virtual databases, and those inner virtual databases combine PlainText and MimeText versions of the same dictionary, the returned entries are attributed to the outer virtual database instead of to the logical child dictionary which supplied the entry. The problem appears to be in the virtual database handler of dicod, rather than in dicoweb. Reproducible test environment ============================= A complete Docker-based test environment is attached to this bug report in: docker.zip It contains: docker-compose.yml docker-compose.override.yml docker-compose.dict-init.yaml The Docker environment is intended to make the problem immediately reproducible. All dictionaries required for the test are already included in the Docker environment. No manual installation of dictionary files is required. Start the test environment with: docker compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.dict-init.yaml up -d After the containers have started, open the local web interface: http://localhost/ Select the database: Группа лексиконов для Танаха в подстрочном переводе на русском языке and search for: 01 The problem should be immediately visible in the resulting dictionary entries. Steps to reproduce ================== 1. Extract docker.zip. 2. Start the complete test environment: docker compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.dict-init.yaml up -d 3. Open the following URL in a web browser: http://localhost/ 4. Select the database: Группа лексиконов для Танаха в подстрочном переводе на русском языке 5. Search for: 01 6. Examine the database name displayed above the returned dictionary entries. The supplied Docker environment contains everything necessary for this test. No manual installation of the dictionaries from dictmime.zip is required. Configuration ============= The test uses two logical dictionaries. Each logical dictionary consists of a PlainText and a MimeText database. The first dictionary is configured as follows: database { name "heb-rus_strong__plain"; handler "dictorg database=dictmime/heb-rus_strong"; visible no; } database { name "heb-rus_strong__mime"; handler "dictorg database=dictmime/heb-rus_strong__mime"; visible no; } database { name "heb-rus_strong"; description "Еврейский словарь Стронга на русском языке"; handler "virtual"; database "heb-rus_strong__plain" nomime; database "heb-rus_strong__mime" mime; } The second dictionary is configured as follows: database { name "ITBYHebConcise__plain"; handler "dictorg database=dictmime/ITBYHebConcise"; visible no; } database { name "ITBYHebConcise__mime"; handler "dictorg database=dictmime/ITBYHebConcise__mime"; visible no; } database { name "ITBYHebConcise"; description "Краткий древнееврейский лексикон"; handler "virtual"; database "ITBYHebConcise__plain" nomime; database "ITBYHebConcise__mime" mime; } These two logical dictionaries are then combined into another virtual database: database { name "ITBYLexicon"; description "Группа лексиконов для Танаха в подстрочном переводе на русский язык"; info <<- EOT --- Группа лексиконов для ITBY --- EOT; handler "virtual"; database "heb-rus_strong"; database "ITBYHebConcise"; } The resulting database hierarchy is: ITBYLexicon | +-- heb-rus_strong | | | +-- heb-rus_strong__plain | +-- heb-rus_strong__mime | +-- ITBYHebConcise | +-- ITBYHebConcise__plain +-- ITBYHebConcise__mime Thus the relevant structure is: virtual | +-- virtual | | | +-- dictorg | +-- dictorg | +-- virtual | +-- dictorg +-- dictorg Expected behavior ================= The result should preserve the identity of the logical child dictionary which supplied the entry. For an entry returned from heb-rus_strong, the result should identify the dictionary as: Еврейский словарь Стронга на русском языке For an entry returned from ITBYHebConcise, the result should identify the dictionary as: Краткий древнееврейский лексикон The internal PlainText/MimeText implementation should be transparent to the client. The outer virtual database: ITBYLexicon should act as a collection of logical dictionaries and should not replace their individual identities in the returned results. Actual behavior =============== When searching for 01 in ITBYLexicon, four definitions are returned. However, each result is displayed as coming from: Группа лексиконов для Танаха в подстрочном переводе на русском языке instead of identifying the logical dictionary which supplied the result. In the web interface the result is displayed in the form: Из словаря Группа лексиконов для Танаха в подстрочном переводе на русском языке: Consequently, when the same search term occurs in several child dictionaries, the user cannot determine which particular dictionary supplied each entry. The attached ScreenCapture.png illustrates the actual result obtained from the local Docker test environment. Control case ============ The problem does not occur when a virtual database directly contains ordinary dictorg databases. For example: database { name "ru-he"; description "Группа русско-ивритских словарей"; handler "virtual"; database "ru-he_ar"; database "ru-he_at"; database "ru-he_bd"; database "ru-he_ch"; ... } Here the hierarchy is: virtual | +-- dictorg +-- dictorg +-- dictorg ... When a search term occurs in several child dictionaries, the individual child dictionary can be identified correctly. The problem appears when there is an additional level of virtual databases: virtual | +-- virtual | | | +-- dictorg | +-- dictorg | +-- virtual | +-- dictorg +-- dictorg This suggests that the problem is specifically related to nested virtual databases. Workaround ========== At present I use a separate PHP script to query the logical dictionaries individually and combine the results. For example, the following local URL demonstrates the desired behavior: http://localhost/static/dict.php?dbname=heb-rus_strong,ITBYHebConcise&word=01&title=Окно%20древнееврейского%20лексикона The PHP script is not part of the bug. It is only a workaround which queries the logical dictionaries separately and therefore allows their individual names to be displayed. The purpose of this bug report is to make this workaround unnecessary by obtaining the correct dictionary identity directly from dicod. Dictionary data supplied separately =================================== The archive: dictmime.zip is not required to run the supplied Docker test environment. It is provided as additional material for developers or package maintainers who want to reproduce the problem independently, without using the supplied Docker environment. The archive contains the dictionary files used by the test: dictmime/heb-rus_strong.dict.dz dictmime/heb-rus_strong.index dictmime/heb-rus_strong__mime.dict.dz dictmime/heb-rus_strong__mime.index dictmime/ITBYHebConcise.dict.dz dictmime/ITBYHebConcise.index dictmime/ITBYHebConcise__mime.dict.dz dictmime/ITBYHebConcise__mime.index These files can be used to configure an independent dicod test installation with the same nested virtual database structure described above. Thus there are two possible ways to reproduce the problem: 1. Recommended: use the supplied Docker environment. Run: docker compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.dict-init.yaml up -d No additional dictionary installation is necessary. 2. Alternatively, build an independent test installation using the dictionary data from dictmime.zip and create the corresponding dictorg and virtual database configuration. Why the Docker test is provided =============================== The Docker configuration is intended to make the bug immediately reproducible with a single command. After running: docker compose -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.dict-init.yaml up -d the tester obtains a complete local environment containing the required dicod configuration, dictionaries and web interface. The tester can then reproduce the problem using an ordinary web browser: http://localhost/ No access to the production server is required, and no manual installation or configuration of the dictionaries is necessary. Possible cause ============== The virtual handler appears to lose or replace the database identity when a result is propagated through nested virtual databases. In the following structure: outer virtual | +-- inner virtual | +-- dictorg the outer virtual database appears to become the database associated with the returned result. The expected behavior would be to preserve the identity and description of the logical child database while hiding the implementation details of its PlainText/MimeText sub-databases. Request ======= Please investigate the handling of nested virtual databases in dicod. If this behavior is confirmed to be a bug, the virtual handler should preserve the identity/name/description of the underlying logical database when returning entries through another virtual database. This is important for dictionary collections in which each logical dictionary has multiple internal representations, such as PlainText and MimeText. Attachments =========== The following files are attached to this bug report: docker.zip dictmime.zip ScreenCapture.png docker.zip contains the complete Docker configuration for an immediately reproducible test environment. All dictionaries required for the test are already included in the Docker environment. dictmime.zip contains the dictionary data used by the test. It is provided for developers or package maintainers who want to configure an independent dicod installation and is not required for reproducing the bug with the supplied Docker environment. ScreenCapture.png shows the actual result obtained from the local reproducible Docker test.