天道酬勤,学无止境

“冲突可序列化”和“冲突等效”有什么区别?(What is the difference between “conflict serializable” and “conflict equivalent”?)

问题

在数据库理论中,“冲突可序列化”和“冲突等效”有什么区别?

我的教科书中有一节是关于可序列化冲突的,但忽略了冲突等价性。 大概这两个概念我都很熟悉,但是我对术语不熟悉,所以我正在寻找解释。

回答1

仅用两个术语以不同的方式描述一件事。

冲突等价:您需要说附表 A 与附表 B 的冲突等价。它必须涉及两个时间表

Conflict serializable : 仍然使用 Schedule A 和 B。我们可以说 Schedule A 是冲突可序列化的。 附表 B 是冲突可序列化的。

我们没有说 Schedule A/B 是冲突等价的

我们没有说 Schedule A 与 Schedule B 发生冲突

回答2

DBMS 中的冲突可以定义为两个或多个不同的事务访问同一变量,并且其中至少一个是写操作。

例如:

T1: Read(X)   
T2: Read (X)

在这种情况下没有冲突,因为两个事务都只执行读取操作。

但在以下情况下:

T1: Read(X)   
T2: Write(X)

有冲突。

假设我们有一个时间表S ,我们可以重新排列其中的指令。 并创建另外 2 个计划S1S2

冲突等效:指的是调度S1S2 ,它们在两个调度中维护冲突指令的顺序。 例如,如果T1T2X写入S1之前必须读取X ,那么它在S2也应该相同。 (应该只为冲突的操作维护排序)。

冲突可串行化:如果S与串行调度等价的冲突(即,事务一个接一个地执行),则称S是冲突可串行化的。

回答3

来自维基百科。

冲突对等

如果满足以下条件,则称调度S1S2是冲突等效的:

  1. 调度S1S2都涉及同一组事务(包括每个事务内的操作顺序)。

  2. S1S2中每对冲突动作的顺序是相同的。

冲突可序列化

当调度与一个或多个串行调度发生冲突时,该调度被称为是冲突可串行化的。

冲突可串行化的另一个定义是,当且仅当它的优先级图/可串行化图(当仅考虑已提交的事务时)是非循环的(如果该图被定义为还包括未提交的事务,则涉及未提交的事务的循环)时,调度是冲突可序列化的事务可能发生而没有冲突可串行化违规)。

回答4

如果调度 S 可以通过一系列非冲突指令的交换转换为调度 S´,我们说 S 和 S´ 是冲突等价的。

我们说调度 S 是冲突可序列化的,如果它是一个等价于串行调度的冲突。

回答5

冲突可串行化意味着冲突等同于任何串行调度。

回答6

冲突等价调度:如果调度 S 可以通过一系列非冲突指令的交换转换为调度 S',我们说调度 S & S' 是冲突等价的。

冲突可串行化调度:如果调度 S 与串行调度等价的冲突,则它是冲突可串行化的。

回答7

定义已经被完美解释了,但我觉得这对某些人来说非常有用。

我开发了一个小型控制台程序(在 github 上),它可以测试任何冲突可串行化的时间表,并且还会绘制一个优先级图。

回答8

如果所考虑的事务调度至少有一个冲突等效调度,则它是冲突可序列化的。

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • Git diff提交范围中的双点“ ..”和三点“ ...”之间有什么区别?(What are the differences between double-dot “..” and triple-dot “…” in Git diff commit ranges?)
    问题 以下命令之间有什么区别?: git diff foo master # a git diff foo..master # b git diff foo...master # c diff手册对此进行了讨论: 比较分支$ git diff topic master <1> $ git diff topic..master <2> $ git diff topic...master <3> 在主题提示和主分支之间切换。 与上述相同。 自从主题分支启动以来,在master分支上发生的更改。 但对我来说还不是很清楚。 回答1 由于我已经创建了这些图像,因此我认为可能值得在其他答案中使用它们,尽管对.. (点-点)和... (点-点-点)之间区别的描述基本上是相同的就像manojlds的回答一样。 通常,命令git diff仅向您显示提交图中恰好两点之间树的状态之间的差异。 git diff的..和...符号具有以下含义: # Left side in the illustration below: git diff foo..bar git diff foo bar # same thing as above # Right side in the illustration below: git diff foo...bar git diff $(git merge-base foo
  • 这些git diff命令之间有什么区别?(What are the differences between these git diff commands?)
    问题 以下git命令之间有什么区别? git diff HEAD git diff HEAD^ git diff --cached或同义词git diff --staged git diff 回答1 git diff HEAD显示自上次提交以来发生的变化。 git diff HEAD^ -显示发生了什么变化,因为在提交前的最新承诺。 git diff --cached显示已通过git add添加到索引中但尚未提交的内容。 git diff显示更改了什么,但是还没有通过git add添加到索引中。 看起来像这样: Working Directory <----+--------+------+ | | | | | | | | V | | | "git add" | | | | diff | | | | | | V | | | Index <----+ diff HEAD | | | | | | | | | V | | | "git commit" | | | | diff --cached | | | diff --staged | | V | | | HEAD <----+--------+ | | | | diff HEAD^ V | previous "git commit" | | | | | V | HEAD^ <--------------------+ 回答2
  • Git提交范围中的双点“ ..”和三点“ ...”之间有什么区别?(What are the differences between double-dot “..” and triple-dot “…” in Git commit ranges?)
    问题 一些Git命令采用提交范围,一种有效的语法是用两个点分隔两个提交名称.. ,而另一种语法则使用三个点... 两者之间有什么区别? 回答1 这取决于您使用的是log命令还是diff命令。 在log情况下,它在man git-rev-parse文档中: 为了从提交中排除可到达的提交,使用前缀^表示法。 例如^ r1 r2表示可从r2到达的提交,但不包括可从r1到达的提交。 设置操作如此频繁地出现,以至于它有一个简写形式。 当您有两个提交r1和r2(根据上面的“指定版本”中所述的语法命名)时,可以要求从r2可以到达的提交(不包括那些从r1可以通过“ ^ r1 r2”到达的提交),并且可以写为“ r1..r2”。 类似的符号“ r1 ... r2”被称为r1和r2的对称差,并且定义为“ r1 r2-不是$(git merge-base --all r1 r2)”。 这是可从r1或r2之一访问的提交集合,但不能同时从两者访问。 从根本上讲,这意味着您将获得两个分支中任何一个的所有提交,但不能同时获得这两个分支中的所有提交。 在diff情况下,它在man git-diff文档中: git diff [--options] <commit>...<commit> [--] [<path>...] This form is to view the changes on the branch
  • 有人可以告诉我git diff在这里有什么区别吗?(Can someone explain to me what difference git diff is seeing here?)
    问题 我在Windows 7上通过msysgit使用git。 最近引起我很多麻烦的一个问题是,当我切换到某些分支时,git认为某些文件已被更改,然后我无能为力以使其停止以为这些文件已更改。 在我的情况下,复制步骤(可能与每个人都不相关)如下: 检出master分支。 检出pristine-3.7分支。 检出pristine-3.8分支。 签出pristine-3.9分支。 此时,git开始假定文件已更改。 例如,这是git diff输出的屏幕截图。 这是在十六进制模式下使用Beyond Compare的同一个文件的差异输出。 最后,git状态输出! 这是怎么回事? 更新问题: 一种可能的解决方案是在本地提交更改,然后删除该提交,而不必将提交中的更改恢复到工作状态。 这是怎么做的? 回答1 我经常遇到这个问题-唯一可行的是: git rm --cached -r . > /dev/null # redirect if output is huge git reset --hard 但请确保您没有要保留的更改 查看git行尾-无法隐藏,重置并且现在无法基于伪造的行尾提交进行变基 某人必须制作一个展示此行为的示例存储库,并将其发布到git跟踪器-这是一个错误(从git reset --hard和co应该立即起作用的意义上来说) 编辑:确保您已阅读所需的阅读材料并设置了
  • git diff --patience和git diff --histogram有什么区别?(What's the difference between `git diff --patience` and `git diff --histogram`?)
    问题 这个较早的问题要求4种不同的Git diff策略之间存在差异,但是唯一可以解释的差异是myers和patience之间的差异,这在其他地方也可以很好地解释。 histogram策略如何工作? 它与patience有何不同? git-diff手册页只说它“将耐心算法扩展为“支持低发生率的常见元素”。 其他页面提到它更快,并且来自JGit,但是没有解释其算法或结果在哪里或如何与patience有所不同。 在哪里可以找到相对于patience算法的histogram算法描述,其详细程度与Bram Cohen最初对耐心算法的描述相同? (如果只是实现性能的问题,没有任何情况会产生不同的结果,那为什么不将它作为patience的新后端来实现呢?) 回答1 此直方图策略在git 1.7.7(2011年9月)中引入,并带有以下说明(如OP所述) “ git diff ”学习了“ --histogram ”选项,以使用从jgit窃取的另一种diff生成机制,这可能会提供更好的性能。 JGit包括src / org / eclipse / jgit / diff / HistogramDiff.java和tst / org / eclipse / jgit / diff / HistogramDiffTest.java 那里的描述相当完整: 直方图差异 Bram
  • git am和git apply有什么区别?(What is the difference between git am and git apply?)
    问题 git am和git apply均可用于应用补丁。 我看不出有什么区别。 我现在看到了一个区别: git am自动提交的,而git apply只触摸文件而不创建提交。 那是唯一的区别吗? 回答1 输入和输出都不同: git apply获取一个补丁(例如git diff的输出)并将其应用到工作目录(或索引,如果使用--index或--cached的话)。 git am接收一个以电子邮件格式设置的提交的邮箱(例如git format-patch的输出),并将它们应用于当前分支。 git am在后台使用git apply,但是在(读取Maildir或mbox并解析电子邮件)和之后(创建提交)之前Maildir更多的工作。 回答2 git apply用于应用直接差异(例如,来自git diff ),而git am用于应用来自电子邮件的补丁和补丁序列(mbox或Maildir格式),与git format-patch 。 git am尝试从电子邮件中提取提交消息和作者详细信息,这就是它可以进行提交的原因。 回答3 使用git am您将应用补丁,因此当您运行git status您将看不到任何本地更改,但是git log将显示补丁已提交给源代码。 但是使用git apply ,就像您自己编写代码一样,您可以在源文件中进行更改,因此git status和git
  • 在jQuery mobile中,tap和vclick之间有什么区别?(In jQuery mobile, what's the diff between tap and vclick?)
    问题 我应该使用哪个事件来收听? 为什么要使用vclick? 我只是不知道该使用哪种情况。 回答1 如果使用jQuery Mobile Tap,则它只能在移动设备上使用。 情况不再如此。 创建VClick是为了弥合台式机/移动设备之间的点击/点击不兼容之间的鸿沟。 现在,您可以自由使用水龙头了,但问题很少。 点按将在iOS平台上失败。 应该改用Touchstart。 例子: VClick 在台式机和移动设备上均可使用。 Android 4.1.1-无延迟 iOS-无延迟桌面Firefox 19和Chrome 25.0.1364.152-无延迟 http://jsfiddle.net/Gajotres/PYPXu/embedded/result/ $(document).on('pagebeforeshow', '#index', function(){ $( document ).on( "vclick", '[data-role="page"]', function() { $( this ).append( "<span style='color:#00F;'>vmouseup fired.</span>" ); }); }); 轻敲: 轻敲 它过去只能在移动设备上运行,现在也可以在台式机浏览器上运行,但是在带有jQuery Mobile 1.1及更低版本的iOS上将失败。
  • count(*)和count(column_name),区别是什么?(count(*) and count(column_name), what's the diff?)
    问题 count(*)和count(column_name) ,在mysql中有什么区别。 回答1 COUNT(*)对结果集中的所有行(或使用GROUP BY的组COUNT(*)计数。 COUNT(column_name)仅计算column_name不为NULL的那些行。 即使没有NULL值,在某些情况下这也会变慢,因为必须检查该值(除非该列不可为空)。 COUNT(1)与COUNT(*)相同,因为1永远不能为NULL。 要查看结果的差异,您可以尝试以下小实验: CREATE TABLE table1 (x INT NULL); INSERT INTO table1 (x) VALUES (1), (2), (NULL); SELECT COUNT(*) AS a, COUNT(x) AS b, COUNT(1) AS c FROM table1; 结果: a b c 3 2 3 回答2 根据列的定义(即,如果您的列允许NULL),您可能会得到不同的结果(在某些情况下,使用count(column)可能会更慢,如Mark所言)。 回答3 COUNT (*) , COUNT (ColumnName)和COUNT (1)之间没有性能差异。 现在,如果您有COUNT (ColumnName)则数据库必须检查该列是否具有NULL值,并且将NULL从聚合中删除。 因此,除非您想要COUNT
  • composer.lock和installed.json有什么区别?(What's the difference between composer.lock and installed.json?)
    问题 我了解composer.lock旨在确定已安装依赖项的确切版本。 但是vendor/composer/installed.json文件的作用是什么? 两者都包含JSON,并且两者都是自动生成的。 回答1 首次安装或更新时会生成composer.lock 。 它包含对所使用确切版本的引用。 应该将其提交到版本跟踪存储库中,以允许还原库的这种精确组合。 installed.json是Composer的内部文件。 当您从composer.json手动删除程序包以从供应商目录中删除文件时,将使用它。 否则,旧的供应商软件包将永远存在。 回答2 Composer似乎将installed.json用作内部存储库,以跟踪供应商目录中实际安装的内容。 我读过composer.lock就是应安装installed.json是安装了什么。 在某种意义上说,具有没有供应商目录的composer.lock文件是有效的。 您运行composer install ,它将安装int composer.lock列出的软件包,并将其写入installed.json 。 作曲家的代码库将installed.json视为本地存储库。 内容被加载到InstalledRepositoryInterface类型的变量中,该变量名为localRepository 。 回答3 您永远不会委托供应商! 您提交composer
  • 克隆和原始远程存储库之间的git diff(git diff between cloned and original remote repository)
    问题 我已经克隆了github存储库,并且在本地未进行任何更改。 Github存储库在同一个分支上进行了提交。 如何找到本地存储库和原始github存储库之间的差异? 如何找到我的工作副本和原始github存储库之间的区别? 如何在本地存储库和同一项目的另一个github存储库之间找到差异? 回答1 1)添加您要比较的任何远程存储库: git remote add foobar git://github.com/user/foobar.git 2)更新您的遥控器的本地副本: git fetch foobar 提取不会更改您的工作副本。 3)将本地存储库中的任何分支与您添加的任何远程对象进行比较: git diff master foobar/master 回答2 回答您的问题的另一种方式(假设您在master上,并且已经执行过“ git fetch origin”,以使您回购有关远程更改的信息): 1)自创建本地分支以来在远程分支上提交: git diff HEAD...origin/master 2)我假设“工作副本”是指您的本地分支,其中包含尚未在远程的某些本地提交。 要查看本地分支上的差异,但远程分支上不存在的差异,请运行: git diff origin/master...HEAD 3)请参阅dbyrne的答案。 回答3 此示例可能对某人有帮助: 注意“ origin
  • .NET Assembly Diff /比较工具-有哪些可用? [关闭](.NET Assembly Diff / Compare Tool - What's available? [closed])
    问题 关闭。 此问题不符合堆栈溢出准则。 它当前不接受答案。 想要改善这个问题吗? 更新问题,使它成为Stack Overflow的主题。 5年前关闭。 改善这个问题 我希望能够在两个程序集之间进行代码级的区分。 到目前为止,我找到的最接近的是Reflector的Diff插件,但是要比较整个程序集是一个手动过程,需要我深入到每个名称空间/类/方法。 到目前为止,我发现的其他工具似乎仅限于API级别(命名空间,类,方法)的差异,而这些差异并不能满足我的需求。 有人知道这样的工具吗? 我的要求(从最高到最低)是: 能够分析/反映同一程序集的两个版本的代码内容并报告差异接受一个文件夹或一组程序集作为输入; 快速比较它们(类似于WinMerge的文件夹差异的) 快速确定两个程序集在代码级别(而不仅仅是API)是否等效的能力允许轻松向下钻取以查看差异导出有关差异的报告 (个人而言,我喜欢WinMerge来处理文本差异,因此具有类似接口的应用程序会很棒) 回答1 NDepend工具提供了许多功能来处理.NET代码差异。 “按更改搜索”面板专用于浏览程序集代码diff: 提出了限制差异和演化的许多代码规则。 他们可以是您编写自己的书或使其适应您的需求的良好开端。 例如看规则: 曾经被100%覆盖但不再存在的类型 // <Name>Types that used to be 100%
  • 比较Git中整个基准的差异(Comparing differences across a rebase in Git)
    问题 假设我只是衍合分支foo上master ,有冲突的。 我想确保在冲突解决期间,我不会因引入额外的更改或丢失更改而意外损坏foo的内容(适用于冲突解决的内容除外)。 我是通过以下方式完成的: diff -u <(git diff `git merge-base master foo@{1}` foo@{1}) \ <(git diff `git merge-base master foo ` foo ) (更新:或者我刚刚想起的git-diff的等价语法... diff -u <(git diff master...foo@{1}) <(git diff master...foo) | mate 这向我显示了master..foo发生的所有更改,都被视为一个补丁,这正是我要检查的最小更改。 但是,调用很复杂,输出也不是完全易于解释。 有没有更好的方法可以完成此任务-提供相同的信息,但要有更好的方法或格式-是我应该将以上内容包装在脚本中? 回答1 我们真正想要展示的是生成的冲突合并差异,就好像我们已经完成了从(a)到(b)的合并操作一样,其中(a)以前基于(上游),而(b)现在基于(上游)。 我们不想要直接的差异。 取而代之的是,我们基本上可以进行合并,但是将结果树强制为$ b ^ {tree},我们已经知道这是我们想要的正确的“终点”点。 或多或少,让我们假设我们有
  • 'git pull'和'git fetch'有什么区别?(What is the difference between 'git pull' and 'git fetch'?)
    问题 想要改善这篇文章吗? 提供此问题的详细答案,包括引文和为什么您的答案正确的解释。 答案不够详细的答案可能会被编辑或删除。 git pull和git fetch什么区别? 回答1 用最简单的术语来说, git pull进行git fetch然后进行git merge 。 您可以随时执行git fetch来更新refs/remotes/<remote>/下的远程跟踪分支。 此操作绝不会更改refs/heads下您自己的任何本地分支,并且可以安全地执行而不更改您的工作副本。 我什至听说有人在后台执行cron作业中定期运行git fetch (尽管我不建议这样做)。 git pull是您要执行的操作,以使本地分支机构的远程版本保持最新,同时还更新其他远程跟踪分支机构。 从git pull的Git文档中: 在其默认模式下, git pull是git fetch简写,后跟git merge FETCH_HEAD 。 回答2 当您使用pull ,Git会尝试自动为您完成工作。 它是上下文相关的,因此Git会将所有提交的提交合并到您当前正在使用的分支中pull自动合并提交,而无需您先对其进行审查。 如果您不严密管理分支机构,则可能会遇到频繁的冲突。 fetch ,Git会从目标分支中收集当前分支中不存在的所有提交,并将它们存储在本地存储库中。 但是,它不会将它们与当前分支合并。
  • 遵循命令时,双破折号做什么?(What does double-dash do when following a command?)
    问题 问题: 双破折号后出现命令时,应用程序应如何解析命令行? (此重复与此不重复) 我知道双破折号通常会做什么: A-表示选项结束,并禁用进一步的选项处理。 -后面的任何参数均被视为文件名和参数。 -的参数等效于- 因此,它将以下内容设置为参数,例如: myapp -f <args> ...然后$ myapp -f -- -a -b将-a和-b视为-f参数,而不是Flags 但是,当需要一个应用程序时会发生什么: myapp cmd <arg> -f <args>... 命令行是$ myapp -f -- test cmd sth ,应将其解析为: myapp收到带有参数test , cmd和sth的-f标志或myapp收到一个cmd命令,后跟sth ,一个-f并带有参数test 我正在为python编写命令行解析器,因此我需要知道它的行为。 多谢 :) 回答1 你写了 $ myapp -f -- -a -b将-a和-b视为-f的参数,而不是标志 不完全的。 双破折号为myapp -a和-b参数。 如果-f期望有一个参数,则使用双破折号会引起错误,因为没有给出这样的参数。 如果您的解析器定义了子解析器,则位于其前面的任何选项均假定为由主解析器定义的选项,并且子命令后的所有选项均属于子解析器。 例如, p = ArgumentParser() p.add_argument("-v"
  • 反应功能性无状态组件,PureComponent,Component; 有什么区别,什么时候应该使用什么?(React functional stateless component, PureComponent, Component; what are the differences and when should we use what?)
    问题 从React v15.3.0知道,我们有了一个名为PureComponent的新基类,以扩展内置的PureRenderMixin 。 我了解的是,在shouldComponentUpdate此方法对shouldComponentUpdate内部的道具进行了较浅的比较。 现在,我们有3种方法来定义React组件: 不扩展任何类的功能性无状态组件扩展PureComponent类的组件扩展Component类的常规组件 一段时间以前,我们曾经将无状态组件称为“纯组件”,甚至称为“哑组件”。 似乎“纯”一词的整个定义现在已经在React中改变了。 尽管我了解这三者之间的基本区别,但是我仍然不确定何时选择什么。 另外,每种性能对性能的影响和权衡是什么? 更新: 这些是我希望得到澄清的问题: 我应该选择将我的简单组件定义为功能性的(出于简单性考虑)还是扩展PureComponent类(出于性能的考虑)? 我为失去的简单性而付出了真正的权衡取舍,从而提高了性能吗? 当我始终可以使用PureComponent以获得更好的性能时,是否需要扩展普通的Component类? 回答1 您如何决定,如何根据我们组件的目的/尺寸/道具/行为在这三者之间进行选择? 使用自定义shouldComponentUpdate方法从React.PureComponent或从React
  • 标准(Myers),最小,耐心和直方图差异算法产生的不同结果的示例(Examples of different results produced by the standard (Myers), minimal, patience and histogram diff algorithms)
    问题 Git提供了这4种diff算法,但是没有任何进一步的信息,它们有什么区别。 每个算法的优点是什么? 在各种情况下算法是否有不同的比较? 回答1 我认为支持多种算法,因为在所有情况下,没有一种算法显然是最佳选择。 差异在于补丁输出的可读性和生成补丁所需的处理时间。 总结一下,这就是我理解的区别: Myers:xdiff(http://www.xmailserver.org/xdiff-lib.html和http://www.xmailserver.org/diff2.pdf)中实现的原始算法,为更改的行优化了“编辑距离” 。 最小:Myers并尝试最小化补丁大小。 耐心:尝试权衡补丁的可读性与补丁大小和处理时间之间的关系。 请参阅`git diff --patience`是什么? 和http://bramcohen.livejournal.com/73318.html或http://alfedenzo.livejournal.com/170301.html进行说明。 直方图:主要是为了提高速度而创建的。 比最初在jgit(http://eclipse.org/jgit/)中开发的Myers和Patience更快 这是Myers,耐心和直方图的速度比较:http://marc.info/?l=git&m=133103975225142&w=2
  • 缺少在angular2(2种差异方式)文档中访问本机元素的正确方法是什么(What's the proper way of accessing native element in angular2 (2 diff ways) docs are scarce)
    问题 在angular2中访问本机元素的正确方法是什么(2种比较方式),所以我看到了使用以下代码的代码: constructor(ele: ElementRef) { let myEl = ele.nativeElement; // do some work on myEl such as jQuery(myEl).hide() ... 以及通过BrowserDomAdapter使用本机dom的代码: constructor(viewContainer:ViewContainerRef) { let dom = new BrowserDomAdapter(); let el = viewContainer.element.nativeElement; let myEle = dom.getElementsByClassName(el, element)[0]; // or jQuery(myEle).hide() ... 我想知道什么是赞成/反对和“正确”的做事方式。 不幸的是,文档似乎仍然稀缺。 我假设后者将通过该界面为您提供WebWorkers支持,但这只是我的假设。 回答1 <div #foo> @ViewChild() foo; ngAfterViewInit(){ foo.nativeElement... } 或如果被排除 @ContentChild() foo
  • 在Hibernate Validator 4.1+中,@ NotNull,@ NotEmpty和@NotBlank有什么区别?(In Hibernate Validator 4.1+, what is the difference between @NotNull, @NotEmpty, and @NotBlank?)
    问题 我似乎找不到能够区分这三个注释之间区别的摘要。 回答1 @NotNull :CharSequence,Collection,Map或Array对象不为null ,但可以为空。 @NotEmpty :CharSequence,Collection,Map或Array对象不为null,并且size> 0 。 @NotBlank :字符串不为null ,并且修剪后的长度大于零。 为了帮助您理解,让我们研究一下如何定义和执行这些约束(我使用的是4.1版): @NotNull约束定义为: @Constraint(validatedBy = {NotNullValidator.class}) 此类的isValid方法定义为: public boolean isValid(Object object, ConstraintValidatorContext constraintValidatorContext) { return object != null; } @NotEmpty约束定义为: @NotNull @Size(min = 1) 因此,此约束使用上面的@NotNull约束和@Size其定义根据对象而有所不同,但应该是自说明的。 最后, @NotBlank约束定义为: @NotNull @Constraint(validatedBy = {NotBlankValidator
  • 在hg或git中的两个完整目录/项目之间有区别吗?(Diffing between two entire directories/projects in hg or git?)
    问题 我继承了最初存储在CVS中的所有版本的项目。 我进行了很多编辑,并尝试比较在原始目录中所做的所有更改,包括新添加的文件和旧文件。 是否有某种用于hg / git的实用程序,可以在其中进行树形比较,或类似的功能? 这么说,在新添加的文件和已删除的文件之间有一个标记,我要求太多吗? 回答1 git diff正是这样做的。 但它仅适用于git项目。 hg diff , svn diff几乎每个版本控制系统都可以diff目录树 回答2 要从两个任意文件或目录简单地以git的diff格式创建一个diff补丁,而无需任何花哨的存储库内容或版本控制: git diff --no-index some/path other/path > some_filename JakubNarębski对knittl答案的评论暗示了答案……为了简单起见,这就是全部命令。 >部分将创建一个文件,并将输出重定向到该文件。 如果您不想要文件,而只想在控制台中打印输出以便可以复制它,则只需删除> some_filename部分。 为了方便复制和粘贴,如果你已经cd版包含原来的目录/文件的目录名为a和修改后的目录b ,这将是: git diff --no-index a b > patch 回答3 从git diff联机帮助页: git diff [--options] [--] [<path>...] [
  • NIB和XIB Interface Builder文件格式之间有什么区别?(What is the difference between NIB and XIB Interface Builder file formats?)
    问题 Interface Builder文件中的nib和xib有什么区别? 回答1 从Interface Builder版本3开始,添加了新文件格式(扩展名为.xib),其功能与.nib相同,不同之处在于它存储在平面文件中,使其更适合存储在版本控制系统和处理中。通过诸如diff之类的工具。 http://en.wikipedia.org/wiki/Interface_Builder#Design 回答2 XIB文件基本上是NIB文件的源文档,几乎可以始终在Xcode中编辑XIB (除非它们已过时或损坏) 。 尽管较新的NIB是压缩的且无法打开,而较旧的NIB是可通过Xcode查看的捆绑软件,捆绑的NIB包含一些源文件/归档文件,其中包括designable.nib ,通常只是重命名的XIB文件。 NIB = N XT I覆盖整个院落乙uilder(NXT = NextStep自动= NS) XIB = X毫升我覆盖整个院落乙uilder 尽管新的归档NIB文件对包括Xcode在内的大多数应用程序都无法打开,但仍可能无法归档。 我在CharlesSoft网站上发现了一个名为NibUnlocker的免费软件应用程序,该应用程序可能会反汇编平面的Nib文件并将其导出为XIB文档。 该应用程序仍然存在很多问题,但有时根据Nib的内容非常准确。 (NibUnlocker是一个非常不正确的名称