SZCND
SZCND
给一条书目记录上传对象 数据库是链表结构，比如划成4k，4096的块，如果要分配记录在4096以下就给一块，如果在4097，比4096多一个字符，那就分2块4096的。举个例子，比如某个公司，给一个员工分了一套三居室的房子，但是要住中间的房间，后来又来了一个员工，那这套三居室有2个房间有人住了，再来一个员工，那这套三居室就住满了。如果再来第四个员工，那就重新分配一套三居室的房间，还是要住满。数据库是按照块来管理的，你往数据库中存1个字节，它是不会给你分1个字节的空间，而是直接分4096，这时候修改这条记录，不断扩大它，把它改成2个字节，3个字节，4个字节，它都是4096。等到这条记录变成4097了，那么占得空间大小就变为4096*2了。 如果删除完了，占1个4096或者多个，这个块也是个链表，专门有一个垃圾站废物链表，就把它收集起来了，但没有还给操作系统，这就是为什么存储到数据库数据目录下的文件，在书目对象下删除了这条记录后依旧没有释放空间。比如上传的记录为1个G，那么用windows操作系统看对应的文件夹，它就是1个G，在书目下删除这个对象记录，它还是1个G，只要你往里面上传的记录大小不超过1个G，它永远就占这么大的空间。等于说这个空间，微软的sql server已经拿到了，但是没还给操作系统，但确实是删除了 测试，给一条书目上传记录，存到了object目录下，然后在dp2内务删除这条记录，查看object目录下该文件是否存在？实际测试结果为不存在了，文件被删除。 普通的书目记录叫00000000\001，对象如果属于它就是00000000\001_0、00000000\001_1，这样的命名方式，是跟对象中某一记录的file元素的id是对应的。 前面7位数字是目录，后面3位是文件名，加在一起是10位。因为操作系统记录了成千上万个文件，找它非常的慢，相当于门牌号一样。每个目录，例如0000000中只有3位数，每条目录中最多有999个记录， 这样算起来记录数就少多了，可以把数据库中几万条对象文件分成一片一片的子目录，这样能提高每次写入，读取的运行速度。 操作系统是windows文件系统是NTFS，FAT32有个bug，文件不能太大，U盘不能超过2G，不然会拷不进去。NTFS最大文件上限为2TB。 sql server 数据库为底层时，首先看databases.xml中的配置然后将文件大小分为2拨，并不看sql server的image类型。如果databases.xml中不配置界限，程序一看超过2G不会往数据库里试一下能不能存，而是直接存到object目录中。如果配置了3个G，欺骗了程序，往数据库里面存，但是存到超过了image的最大值了，就中断了，并且会有提示。 oracle，sqlite，mysql都是写入对象文件的，不写入数据库的，操作系统有个2G的问题，过2G也是过个坎。 postgresql数据库bytea字段，比如现在有1k，再给它1k，就追加在后面，但是postgresql非常在意事务性，（事务性是指：这个字段里面原来是1k，现在再往里面写1k，写成功了就是2k。它考虑的是，在写第二个1k，写到一半的时候，如果出现错误，事务要回滚，回滚完之后，把一个完全没有被干扰过的，原样的东西还给你。就等于说，要么成功，2段都写进去了，要么失败以后还原到没写的状态。） 数据库是如何达到事务性的目的？ 你不是要追加吗？（以前这条记录就是1k，它把这条记录复制过去，产生一条新纪录，然后在1k上满足要求，追加第2个1k，变成2k。而你看到的是，你在后面追加了1k，而数据库是把原来的记录藏起来，复制了一个新纪录，复制了1k，然后再往后面追加1k，总共操作了3k） 这种操作非常吓人，比如上传对象上传到1个G了，你在后面追加1个G多1K，它先把1G保存起来，然后复制出来产生的记录，第二个1G，然后在这后面加了1K，瞬间磁盘就扩大了1倍。本来上传1个1K，结果产生了1个1G很大的文件，而且这个文件也没有回收，要等到你执行一个回收的命令，才会回收。（微软的sql server不会有这个问题）
在dp2内务读者窗装载一条读者记录，在“对象”上传一个文件，保存，然后回到xml属性页。 多了一条` ` 其中`dprms:`是名字空间的前缀，（前缀就叫dprms：）是由`xmlns:dprms="http://dp2003.com/dprms" `定义的，其中`http://dp2003.com/dprms`是URI，这是前缀对应的URI，就是名字空间的URI。file元素多了一个dprms：的前缀，`dprms:file `就是带名字空间的元素。id没带名字空间，是个普通的属性。 开发的原理：可以用API往数据库里写一条读者记录，只要在xml中包含一个file元素（dprms:file id=“number”）那么这条记录里面就会有一个对象，但是刚保存的时候这个对象是个空对象，没有什么内容，但对象已经存在了。这是不需要上传对象的，什么1G，2G的，只要在这条记录里面产生一个file元素。 打开dp2rms找到这个读者，装载到xml纯文本，下方多了一条记录（服务器端别名，状态，本地物理路径.....），在xml纯文本中删除以下内容，然后保存 ``` ``` 保存完之后下方的记录没有了，这是因为这条记录是绑在file元素上的，删除了file元素就会有这个对象，我们没有叫“删对象”的API，所以只能删除元素集记录，（xml叫元素集记录），通过它删掉file元素，间接达到删对象的目的。file元素和对象是一致的，捆绑死的，要删就会一起删掉。 再次将dp2内务中以下内容``输入到刚才dp2rms删除的位置，并保存，提示“下载资源文件元数据失败，原因：ID为"00000000001_0"的记录不存在”状态为“已上载”但是“尺寸”“媒体类型”“时间戳”都不存在，这里有点问题，谢老师再研究一下。 总结：API往里面创建一个对象，是没有创建对象的功能，是通过写入file元素创建对象，上传是有意义的，因为把对象真的上传。再次回到dp2内务该读者的对象属性页中，内容为ID是0，状态是已上载，但是后没有东西，它没有尺寸，这时再上传文件到id=0这条记录中，会覆盖它。例如这条id=0记录的文件为2G，再上传到这个id 1G的文件会覆盖它，尺寸就是1G。 对象是和书目一体的，删除书目对象也不会存在
## 问题说明 20220427总结：在测试拼音、词库的时候发现问题：原本以为没有拼音服务器URL不能加拼音，但实际操作的时候能够给书目的题名加上拼音。向开发老师反馈，经了解，这是一个非常有用的功能，即使在没有配拼音URL或在封闭网络的情况下，在dp2内务，帮助/数据文件夹中，有一个本地的pinyin.xml文件，这也是可以提供拼音的。但是，本地pinyin.xml不太好，拼音服务器优于pinyin.xml，网络条件许可优先用拼音库。 为了测试，进行以下操作 1. 故意删除pinyin.xml，去掉拼音服务器URL，然后在给题名加拼音，这个时候有个下载文件的对话框一闪而过，然后在数据文件夹中就看到多了一个pinyin.xml的文件，而且题名的拼音也添加成功了。 2. 故意删除pinyin.xml，去掉拼音服务器URL，然后给题名加拼音，这个时候提示“本地没有xxx文件，下载失败”，拼音没有加成功。 结论：在封闭网络环境下，例如不能上外网的单位，下载是不成功的，这时需要通过usb或刻盘将pinyin.xml搞进去，这样可以正常使用拼音。 问题： 普通的，最傻的加拼音的方式是单个给字加拼音，例如“银行”，先给“银”加拼音，再给“行”加拼音，不能把“银行”联系起来一次加两个拼音。（pinyin.xml是这么加的）。而正常的用拼音服务器的URL，也就是用拼音库加拼音是非常高级的，给它一大段话一次性的加拼音，而不是单个字去加拼音，是前端让服务器加拼音得电时候是一起提交的，然后服务器一下子将所有拼音都返回来。比如题名有30个字，不是调30次API加拼音，而是调1次API发送30个字。 打个比方，你去定外卖，早上订了油条豆浆别人送过来了，中午订了米饭别人送过来了，晚上订了红烧肉还是送过来了，这就是低级的加拼音的方法。而高级的方法是，你定了一天3顿的餐，由送餐公司给你安排，早上是油条豆浆，中午是米饭，晚上是红烧肉，不会给你早上安排油条豆浆，中午还是安排油条豆浆，这样吃的就烦了。 再说的简单一点，低级的送餐公司是你点什么他就送什么，不管重不重复，吃的健不健康，而高级的送餐公司是你包月，他给你一天三顿安排的最营养，合理搭配。这就是高级的方式，你将30个字一次性交给服务器，它会把这些字切成一个一个的词，例如30个字里面有“银”和“行”，它就自动切割成“银行”一个词，而“银行”这个词曾经有人给它加过拼音，选的“银”就是yin，“行”就是hang，然后就被记录下来，记到了词库里面。 打开dp2rms找到“词”这个库，检索出“银行”，双击装载进一个详细窗。根元素为P，P元素里H属性，H属性里的值叫“银行”,P元素下有个“pinyin”元素，pinyin元素里有个属性叫C，C属性有个值例如471，拼音这个元素有内嵌的文本叫“Yin Hang”例如 ``` Yin Hang ``` H属性的意思是“汉字”的意思，pinyin元素就叫拼音，472就是有472个人用过“yin hang”这个正确的拼法。如果在这里将“yin hang”改为“yin xing”那给题名中“银行”添加拼音的时候会默认为“yin xing”，这是按照使用人数最多的优先选择 ``` Yin Xing Yin Hang ```...
## 说明 20220424在dp2内务创建mongodb日志库，恢复借阅历史的时候出错，发现出错的日志内有不合法的内容。在日志窗装载该日志，也提示出错，且无法装载具体出错的日志记录。需要在日志窗修复，修复的过程是直接删除错误的日志
测试最新版本兼容rfid/ownerInstitution/@version的测试 `` 1. version=0.01版本中“/”表示前方一致，会自动在后面增加“*”。“$”表示精确一致，可进行精确匹配。version缺省时默认为0.01版本 2. version=0.02版本中“/”前方一致功能删除，不会自动增加“*”，“$”精确一致模式删除，无法进行精确匹配，同时新增馆代码/第一中学（馆代码+读者单位）、馆代码/readerType:本科生（馆代码+读者类型）的匹配方式，同时若version的值超过0.02，也都默认为0.02（版本号需有小数点），不会对使用产生影响 详细内容见https://github.com/DigitalPlatform/dp2/issues/942
## 测试大纲 一、 1. 书目记录保存成功（修改），下级记录保存成功 2. 书目记录保存成功（修改），下级记录未修改，不需要保存 二、 3. 书目记录保存失败（修改），下级记录保存成功 4. 书目记录保存失败（修改），下级记录未修改，不需要保存 三、 5. 书目记录保存成功（修改），下级记录保存失败 四、 6. 新增一条书目记录保存失败/成功，下级记录全部修改保存成功
测试dp2内务系统管理窗
## 测试大纲 对dp2内务系统管理窗进行测试 1. 测试“数据库”，确保能够正常创建、修改、删除，初始化，刷新定义。 2. 测试“OPAC”，添加，修改，删除普通库。 3. 测试“查重方案”，确保在系统管理中设置完后，在种册窗的“查重”中正确展示 4. 测试“馆藏地”，确保能够新增，修改，删除 5. 测试“排架体系”，确保能创建，修改，删除 6. 测试“脚本程序”，删除内容并保存，是否能够有提示 7. 测试“条码校验”，确保配置的函数能够起作用 8. 测试“值列表”，确保可以在其中添加内容，正常使用 9. 测试“流通权限”，确保可以新增、删除“读者类型”和“图书类型” 10. 测试“开馆日历”，确保可以新增、修改、删除开馆日历 11. 测试“内核”页面，确保在backup可以上传、下载文件
## 测试大纲 升级 dp2OPAC 时，观察虚拟目录中是否存在 __filelist.config 文件，如果存在，则按照它删除以前残留的文件；否则会把虚拟目录 bin 子目录中以前版本残留的 system.*.dll 文件删除，升级完成后，dp2OPAC 虚拟目录中会留下一个 __filelist.config 文件，表示本次安装所拷入的全部(可执行)文件。用浏览器是无法获取该文件的内容。 1. 存在 __filelist.config 文件，bin目录中添加Systerm.Runtime.dull，升级opac后依旧存在，但是__filelist.config 文件中不会有记载。 2. 存在 __filelist.config 文件，把Systerm.Runtime.dull文件添加到bin目录下，然后把该路径添加到__filelist.config中，升级opac后会删除。 3. 不存在__filelist.config 文件，添加Systerm.Runtime.dull，升级opac后会删除该文件。 4. 在浏览器中不能打开__filelist.config文件。 5. 打开opac的安装包，检查文件数量是否与__filelist.config...
## 测试大纲 1. 预期应删除多余的system.*.dll 2. 预期不应删除多余的非system.开头的dll 3. 针对同名的dll，预期新版本会覆盖原来的dll