Open renyh opened 8 months ago
问题:在实体查询窗发现按创建时间检索时,选择是的rfc1123格式的时间范围,发现提示不合法的utime。
检查原因是因为中文图书实体库的创建时间检索点配置的convertquery是utime,也就是检索词输入的时间格式需要为utime格式才行,不认rfc1123的格式。
<table ref="createTime" /> </key> <table name="createTime" id="11" type="createTime"> <convert> <number style="rfc1123time" /> </convert> <convertquery> <number style="utime" /> </convertquery> <caption lang="zh-CN">创建时间</caption> <caption lang="en">CreateTime</caption> </table>
由于实体库的结构比较单纯,不论是中文图书下的实体库,还是西文图书下的实体库,结构都是一致的,所以开发实体查询窗时,没有像书目查询窗那样做复杂的设计,检索词旁边的选择时间面板没有根据实体库的配置做限制处理。所以界面上是有两个格式rfc112和utime的输入界面,但实际创建时间这个检索点仅支持utime格式。
目前有3种解决方案: 1) 就按目前的配置的来,当在实体查询窗检索时,检索词选择用utime格式,不要选择rfc1123的格式。 2) 改进发行包的keys配置文件,将convertquery的style改为freetime,freetime支持rfc1123、utime、手动输入的日期等格式。 3) 改进代码支持utime和rfc1123只要符合其中一种格式即可,目前convert的加工逻辑是:可以配置以,号分隔的多种style,但处理逻辑是按照叠加处理的方式,改进增加支持|分隔,表示或的关系,只要其中一种符合即可。
目的convert处理是按叠加的方式来处理,不是支持其中一种,下面是一个示例。
<table name="location" id="6"> <convert> <string style="split,upper"/> </convert> <convertquery> <string style="upper" /> </convertquery> <caption lang="zh-CN">馆藏地点</caption> <caption lang="en">Location</caption> </table>
2024-02-27 10:50:11Z
<key> <xpath nstable="">//marc:record/marc:datafield[@tag='998']/marc:subfield[@code='u']</xpath> <from>operTime</from> <table ref="operTime" /> </key> <table name="operTime" id="17" type="opertime"> <convert> <number style="utime" /> </convert> <convertquery> <number style="utime" /> </convertquery> <caption lang="zh-CN">操作时间</caption> <caption lang="en">OperTime</caption> </table>
2002
<key> <xpath nstable="">//marc:record/marc:datafield[@tag='210']/marc:subfield[@code='d']</xpath> <from>publishtime</from> <table ref="publishtime" /> </key> <table name="publishtime" id="10" type="publishtime"> <convert> <number style="freetime" /> </convert> <convertquery> <number style="freetime"/> </convertquery> <caption lang="zh-CN">出版时间</caption> <caption lang="en">Publish Time</caption> </table>\
Mon, 04 Mar 2024 16:39:33 +0800
<key> <xpath>*/operations/operation[@name='create']/@time</xpath> <from>operTime</from> <table ref="createTime" /> </key> <table name="createTime" id="11" type="createTime"> <convert> <number style="rfc1123time" /> </convert> <convertquery> <number style="utime" /> </convertquery> <caption lang="zh-CN">创建时间</caption> <caption lang="en">CreateTime</caption> </table>
问题:在实体查询窗发现按创建时间检索时,选择是的rfc1123格式的时间范围,发现提示不合法的utime。
检查原因是因为中文图书实体库的创建时间检索点配置的convertquery是utime,也就是检索词输入的时间格式需要为utime格式才行,不认rfc1123的格式。
由于实体库的结构比较单纯,不论是中文图书下的实体库,还是西文图书下的实体库,结构都是一致的,所以开发实体查询窗时,没有像书目查询窗那样做复杂的设计,检索词旁边的选择时间面板没有根据实体库的配置做限制处理。所以界面上是有两个格式rfc112和utime的输入界面,但实际创建时间这个检索点仅支持utime格式。
目前有3种解决方案: 1) 就按目前的配置的来,当在实体查询窗检索时,检索词选择用utime格式,不要选择rfc1123的格式。 2) 改进发行包的keys配置文件,将convertquery的style改为freetime,freetime支持rfc1123、utime、手动输入的日期等格式。 3) 改进代码支持utime和rfc1123只要符合其中一种格式即可,目前convert的加工逻辑是:可以配置以,号分隔的多种style,但处理逻辑是按照叠加处理的方式,改进增加支持|分隔,表示或的关系,只要其中一种符合即可。
目的convert处理是按叠加的方式来处理,不是支持其中一种,下面是一个示例。
三种时间格式配置
utime
freetime
rfc1123time