首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

低代码平台的撤销与重做如何设计?

在上一篇文章文章低代码平台的属性面板该如何设计?中聊到了低代码平台的属性面板的设计,今天来聊一下画布区域的撤销、重做的设计。 撤销、重做其实是我们平时一直在用的操作。...这个功能是很常见的,他可以极大的提升用户体验,提高编辑效率,但是用代码应该如何实现呢?再具体点,在我们的低代码平台,针对画布区域元素的一系列操作,又该如何去设计呢?...默认情况下,用户在画布的一系列操作会改变整个画布的呈现状态: 在进行到某个操作时,用户是可以回退到之前的状态的,也就是撤销: 当然在进行撤销操作后,用户是可以恢复这个操作的,对应的就是重做: 来看下之前画布的数据结构...可以看到在添加历史记录的过程中,多了一个changeType字段来区分是什么类型的变更: type changeType = 'add' | 'modify' | 'delete' 这个也是为后面的撤销/重做做铺垫...还有一个场景是:在撤销/重做的过程中,又正常对画布区域执行了操作。

75530

MySQL日志 - Redo Log重做日志

另一方面,事务包含持久性的特性,就是说对于一个已经提交的事务,在事务提交后即使系统发生了崩溃,这个事务对数据库中所做的更改也不能丢失。 那么如何保证这个持久性呢?...Redo的组成 Redo Log可以简单分为以下两个部分: 重做日志的缓冲 (Redo Log Buffer) 保存在内存中,是易失的。...那么对于InnoDB来说就存在一个问题,如果交给系统来同步,同样如果系统宕机,那么数据也丢失了(虽然整个系统宕机的概率还是比较小的)。...针对这种情况,InnoDB给出 innodb_flush_log_at_trx_commit 参数,该参数控制 commit 提交事务时,如何将 Redo Log Buffer 中的日志刷新到 Redo...(系统默认master thread每隔1s进行一次重做日志的同步),事务提交不会触发redo写操作,而是留给后台线程每秒一次的刷盘操作,因此实例crash将最多丢失1秒钟内的事务。

2K30

重做系统给硬盘分配合适的空间(分区助手)

电脑的硬盘是存放我们数据的地方,但是有一个问题就是我们的系统盘(默认的是C盘)一般会很快的就被各种文件占满,但是更可气的是别的盘还没用,造成这样的情况的原因是以下几种: 1、配置电脑的时候C盘是用固态盘分的...,为了启动系统的时候快,所以很多的软件也是直接安装到C盘的。...总之不管什么原因吧,安装系统的时候都会提示说给系统盘分配一定的空间,其实这个不建议很大,最好是不超过99G,原因很简单,百度解释的太繁琐,简言之就是系统盘越大,文件越多,开机读取系统映像文件的速度就越慢...但是如果只分配5G的话,是很小,但是系统文件都放不下肯定也是不行的,所以最好的是50-99G。

82010

dotnet 文档应用的撤销重做设计

从需求层面上讲,撤销就是撤回到上一个步骤,而重做或者说恢复其实就是在恢复撤销的步骤。可以看到越在后面添加的操作,在撤销的时候越快进行撤销。而越早撤销的操作,在重做的时候就越早重做。...,但按照本文的编写方法,如果一开始就来开设计类,我预计将会十分无聊 在定义好了 撤销重做栈 之后,咱将会遇到一个问题,那就是这个 撤销重做栈 的代码应该如何写?...因此咱需要有一个足够通用类型用来定义撤销重做操作 最基础的撤销重做操作其实只有两个动作,一个是就是被撤销,另一个就是被重做恢复,可以定义的类型如下 interface IOperation {...另外,从撤销重做的业务上,也不需要使用抽象类,只需要有撤销和重做两个方法就可以 在应用程序可以根据业务定义多个撤销重做栈的内容,例如说做一个和 PPT 差很多的软件,有编辑和播放两个不同的界面,这两个界面的撤销重做相互独立...在文档内容很多,保存一次需要大量的时候时,就需要用到增量的功能,那么如何实现增量?

62140

Oracle 联机重做日志文件(ONLINE LOG FILE)

1.联机重做日志 记录了数据的所有变化(DML,DDL或管理员对数据所作的结构性更改等) 提供恢复机制(对于意外删除或宕机利用日志文件实现数据恢复) 可以被分组管理 2.联机重做日志组...在事务提交的时候(COMMIT) Redo Log Buffer 三分之一满 Redo Log Buffer 多于一兆的变化记录 在DBWn写入数据文件之前 3.联机重做日志成员 重做日志组内的每一个联机日志文件称为一个成员...日志组被删除后,物理文件需要手动删除(对于非OMF) ALTER DATABASE DROP LOGFILE GROUP n 11.日志的重定位及重命名 所需权限 ALTER DATABASE 系统权限...复制文件到目的位置操作系统权限(写权限) CURRENT状态组内的成员不能被重命名 建议该行为之前备份数据库 重命名或重定位之后建议立即备份控制文件 重定位及重命名的两种方法 添加一个新成员到日志组...CONNECT BY PRIOR) Oracle 用户、对象权限、系统权限 Oracle 角色、配置文件 SQL 基础--> 集合运算(UNION 与UNION ALL)

1.5K20

Oracle丢失重做日志的几种场景恢复

实验环境:RHEL6.4 + Oracle 11.2.0.4 一、丢失重做日志组中成员 1.1 故障模拟 1.2 处理方法 1.3 实际处理过程 二、丢失重做日志组 2.1 丢失INACTIVE重做日志组...2.2 丢失ACTIVE重做日志组 2.3 丢失CURRENT重做日志组 Reference 环境准备 SQL> set linesize 160 SQL> col member for a80 SQL...二、丢失重做日志组 2.1 丢失INACTIVE重做日志组 2.1.1 清除归档的INACTIVE重做日志组 SQL> alter database clear logfile group 2; Database...2.1.2 清除未归档的INACTIVE重做日志组 #清除未归档的INACTIVE重做日志组,不会丢失任何已提交事物,但清除后必须完全备份,从而确保可以执行完整恢复。...2.3 丢失CURRENT重做日志组 数据库mount模式下执行不完整恢复,最后使用RESETLOGS打开数据库。

37010
领券