entity

1、RESTful发展背景及简介 网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备......）。因此，必须有一种统一的机制，方便不同的前端设备与后端进行通信。这导致API构架的流行，甚至出现"APIFirst"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 REST（Representational State Transfer）表述性状态转换，REST指的是一组架构约束条件和原则。 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 2、RESTful设计风格 2.1、推荐格式 1）url格式： http(s): // server.com/api-name/{version}/{domain}/{rest-convention} {version}代表api的版本信息。 {domain}是一个你可以用来定义任何技术的区域(例如：安全-允许指定的用户可以访问这个区域。

事情发生在Dynamics CRM 8.2.2版本，客户新升级到这个版本几个月的时间。 突然有一天，客户反映为什么我们打开CRM Form页面的时候loading的时间这么长呢？大概会需要5-15分钟呢！并且每一个user的加载时间还不一样 >_< 我第一个反映就是，最近我们没更新环境啊，为什么突然会出现这个问题呢，一定是微软的bug，哼哼。 但冷静下来细想一下，还是需要提供一些东西的，比如如何证明是微软的bug？对此经过一系列推理、诊断、Google后，大概定位了一个方向RecentlyViewedXml的缓存。 或者也可能是网络问题？再或者也可能是DB性能问题？ 对于以上几点猜测，于是总结了以下几点检查条件： 1、 让加载慢的User浏览器中输入https://CRMUrl/tools/diagnostics/diag.aspx，点击Run，等待测试结果，这个是对于网络延迟、带宽的诊断 2、 同样让加载慢的User打开加载慢的Entity Form，比如Case，加载完成后按CTRL+Shift+Q，弹出页面中点击Enable后刷新页面，页面再次加载完成后CTRL+Shift+Q，最后Create CSV Report 3、 收集CRM Trace log，为了后续根据CSV中的耗时多的RequestID查Log中对应的SQL之类信息 4、 最后Disable

　　前几天部署了一个网站，原来我一直是发布完成之后，通过ftp把文件上传上去，有几个大佬给我说了多阶段构建，此时我就不需要发布再搞了，直接将项目添加docker支持。 #See https: // aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging. FROM mcr.microsoft.com /dotnet/core/aspnet: 3.1 -buster-slim AS base WORKDIR / app EXPOSE 80 FROM mcr.microsoft.com /dotnet/core/sdk: 3.1 - buster AS build WORKDIR / src COPY [ " amusinghoS.App/amusinghoS.App.csproj " , " amusinghoS.App/ " ] COPY [ " amusinghoS.Entity/amusinghoS.EntityData.csproj " , " amusinghoS.Entity/ " ] COPY [ " amusinghoS.Shared/amusinghoS.Shared.csproj "

最近接触搜索相关的内容，所以熟悉下solr的使用以及如何在java中使用solr实现搜索功能。 1、solr简介 Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。 2、倒排索引 有的人会疑惑，搜索通过数据库也能直接查到为什么还要solr这类搜索引擎。例如我现在要搜索"solr"相关的内容，通过数据库模糊匹配%solr%可以查到，数量少的话查询速度还挺可观，如果数据量到达百万级千万级甚至更多，可能查出来得猴年马月了。 而solr用的倒排索引可以解决这一问题。 什么是倒排索引，先说下正排索引。 假如我有部分数据 文档id 文档内容 1 solr的使用以及如何在java中使用solr实现搜索功能 2 solr是一个独立的企业级搜索应用服务器 3 倒排索引和正排索引 4 搜索引擎 假如我要搜索solr，通过正排索引就是文档id作为索引，找到内容包含solr的文档。文档数量多了之后极大增加的搜索时间。 而倒排索引是将文档内容分词后建立索引。 单词内容 文档id solr 1,2 java 1 搜索 1,2,4 索引 3 服务器 2 此时我要搜索solr时直接通过单词内容索引，找到文档id列表

本次主要是从基础开始配置SpringMVC，包括环境搭建，参数传递，返回值，重定向等细节的讲解。当然最后还会实现对Mysql名为“test”数据库的“jvm”表的增删改查。 SpringMVC的配置 项目准备 我用的是IDEA，首先新建一个WebApplication项目，然后到入jar包， 接着配置一个Tomcat用来启动项目，需要注意的是，你需要在Project Structure->Artifacts的里面添加热部署，（我的默认有一个war exploded）在deployment里面将右边的jar包全选后右击put into web lib的下面。当然后面还会用的jstl和servelt.api这两个jar包，你可以一起导入。 包结构设计 这里主要讲一下spring-mvc.xml的内容，它是一个spring的配置文件，新建是可以在XML Configuration File->Spring Config里面新建文件。需要加一些语句，包扫描声明以及识别mvc注解。里面还需建一个bean对象，是视图解析器，添加返回值路径前缀与后缀。 之后，我们就要在web.xml声明MVC请求中的DispatcherServlet。 Controller 控制器首先要定义@controller注解和@RequestMapping注解。 对于参数传递可以写在函数后面用

介绍一下我们最近在COLING'2020上的一个在预训练模型中加入实体知识的工作： CoLAKE: Contextualized Language and Knowledge Embedding ​ arxiv.org 代码： https:// github.com/txsun1997/Co LAKE 在这篇文章里我们主要想做两件事： 在预训练语言模型的同时也学习一套知识表示 ，以在需要知识的下游文本任务上表现更好，例如实体链接、关系抽取等。（由于实体数量通常很多，之前的一些工作大多使用TransE等算法预先训练好实体表示然后融入到PLM中去，之后不再随PLM一起更新） 在加入实体的同时也加入它的上下文（context），允许模型在不同语境下关注实体的不同邻居，同时学习文本和知识的上下文表示。 （之前的模型只完成了文本的contextulization而没有完成知识的contextualization） 为了做成这两件事，CoLAKE把文本和知识的上下文揉在了一张graph中作为训练样本，我们叫word-knowledge graph，然后在这张graph上做MLM来同时学习文本和知识的表示。 CoLAKE 具体地，给定一段文本，我们将其视为多个单词节点全连接形成的word graph，接着我们把其中提及实体的单词节点替换为对应的实体节点（这类实体节点被称为anchor node）