Рано или поздно многие пользователи системы DSpace сталкиваются с нехваткой возможностей стандартного реестра метаданных DublinCore. Кому-то необходимо отдельным полем описать код специальности ВАК, кому-то указать даты проведения конференции, кому-то уточнить источник поступления/оцифровки документа, или его тип.
В принципе, DSpace позволяет ввести дополнительный реестр метаданных, который, например, можно назвать local.
Пример использования дополнительных полей можно найти тут.
Если внести новые «поля» в параметр webui.itemdisplay.default файла dspace.cfg и соответствующим образом модифицировать перевод — поля нового реестра метаданных можно без проблем созерцать и в кратком виде записи, в т.ч. на нескольких языках, как, например, тут.
Всегда есть соблазн дополнить существующий DC реестр метаданных, но тогда начинаются проблемы с импортом и экспортом, PMH харвестом и другими процедурами, в рамках которых от DSpace ждут чистый DublinCore.
Ситуация, описываемая далее характерна для «старых» версий DSpace, версия 4.1 от неё свободна, а заключается ситуация в следующем — вводим реестр метаданных local, вводим поле local.type, запускаем dspace stat-initial и получаем:
Using DSpace installation in: C:\dspace
Exception: ОШИБКА: подзапрос в выражении вернул больше одной строки
org.postgresql.util.PSQLException: ОШИБКА: подзапрос в выражении вернул больше одной строки
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1531)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1313)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:258)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at org.dspace.storage.rdbms.DatabaseManager.query(DatabaseManager.java:284)
at org.dspace.storage.rdbms.DatabaseManager.querySingle(DatabaseManager.java:330)
at org.dspace.app.statistics.LogAnalyser.getNumItems(LogAnalyser.java:1255)
at org.dspace.app.statistics.LogAnalyser.processLogs(LogAnalyser.java:498)
at org.dspace.app.statistics.CreateStatReport.statMonthly(CreateStatReport.java:181)
at org.dspace.app.statistics.CreateStatReport.main(CreateStatReport.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:183)
C:\dspace>
Суть в том, что в некоторых версиях DSpace имел место такой вот кривенький SQL запрос:
Который собственно два значения и возвращал. Если перевести запрос в человекопонятный вид, то он будет звучать так: Найдем все поля *.type со значением Thesis or Dissertation в промежутке от 01.12.2013 до 31.12.2013, сложим их, и выдадим результат. Но проблема в том, что и dc.type и local.type под эти условия попадают. И возвращает система два результата, в случае с local.type она возвращает ноль.
Данная ситуация была описана здесь в 2011 году в пору актуальности DSpace 1.7, но не была исправлена и в 1.8. Там человек получил ту же проблему, использовав дополнительный реестр метаданных от плагина Europeana.
Собственно, решения у данной проблемы три:
- 1. Обновить DSPACE
- 2. Избегать совпадения названий полей реестра метаданных DC и своего собственного. Имеющуюся проблему легко устранить просто переименовав поле в реестре метаданных один раз и поправить перевод и файл конфигурации DSpace.
- 3. Залезть в код DSpace и модифицировать SQL запрос, до вида:
SELECT COUNT(*) AS num FROM item WHERE in_archive = TRUE AND withdrawn = FALSE AND item_id IN ( SELECT item_id FROM metadatavalue WHERE metadata_field_id = ( SELECT metadata_field_id FROM metadatafieldregistry WHERE element = 'date' AND qualifier = 'accessioned') AND text_value::TIMESTAMP > '2014-08-01'::TIMESTAMP AND text_value::TIMESTAMP < '2014-08-31'::TIMESTAMP ) AND item_id IN ( SELECT item_id FROM metadatavalue WHERE text_value LIKE '%Thesis or Dissertation%' AND metadata_field_id = ( SELECT metadata_field_id FROM metadatafieldregistry WHERE element = 'type' AND qualifier IS NULL LIMIT 1) );