时空漫步者的日记

github向服务器commit时，若有大于100MB的文件会commit失败，同时报错提示。若要将大文件顺利提交，可以通过以下步骤。 如果版本库已经执行了commit、push操作，记录中已经有了大文件，那么需要先把大文件从版本库记录中删除 1，删除错误缓存索引 对于文件： 1git rm --cached path_of_the_file 对于文件夹: 1git rm --cached -r path_of_the_dir 2，重新提交 修改提交信息：git commit --amend 重新提交：git push origin master 这样就把所有小文件都提交到远程仓库了 使用Git Large File Storage进行大文件提交 1，安装教程：https://github.com/git-lfs/git-lfs/wiki/Installation 2，查找大文件，并把大文件加入大文件track中 查找大文件：find ./ -size +100M 把上述查找到的大文件通过 git lfs track "path_of_the_file&quo ...

借助lambda filter 12345678def foo(a, b, c): return a < b and b < cmyTuple = (1, 2, 3, 4, 5, 6)# 找到大于1，小于4的值print(list(filter(lambda x: foo(1, x, 4), myTuple)))# (2, 3) map 12345678910def func(x, y): print(x, y) return x + ya = [1, 2]data = list(map(lambda x: func(x, 88), a))print(data)# 1 88# 2 8# [89, 90]

12345from sqlalchemy import funcquery_ = query_.filter( func.json_extract(models.Person.data, f'$.{key}') == value,)

初步了解更新锁（U）与排它锁（X） 有类似这样的表及数据12345678910111213CREATE TABLE dbo.tb( c1 int, c2 char(10), c3 varchar(10));GODECLARE @id int;SET @id = 0;WHILE @id <5BEGIN; SET @id = @id + 1; INSERT dbo.tb VALUES( @id, 'b' + RIGHT(10000 + @id, 4), 'c' + RIGHT(100000 + @id, 4) );END; 在查询一中执行更新操作12345BEGIN TRANUPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 2;WAITFOR DELAY '00:00:30';UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 5;ROLLBACK; 在查询一执行开始后，马上在查询二中执行 ...

必要条件 互斥条件 资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。 不可剥夺条件 进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。 请求和保持条件 进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。 循环等待条件 在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路，环路中每一个进程所占有的资源同时被另一个申请，也就是前一个进程占有后一个进程所深情地资源。以上给出了导致死锁的四个必要条件，只要系统发生死锁则以上四个条件至少有一个成立。事实上循环等待的成立蕴含了前三个条件的成立，似乎没有必要列出然而考虑这些条件对死锁的预防是有利的，因为可以通过破坏四个条件中的任何一个来预防死锁的发生。 死锁预防我们可以通过破坏死锁产生的4个必要条件来 预防死锁，由于资源互斥是资源使用的固有特性是 ...

记录锁（record lock）这是一个索引记录锁，它是建立在索引记录上的锁（主键和唯一索引都算），很多时候，锁定一条数据，由于无索引，往往会导致整个表被锁住，建立合适的索引可以防止扫描整个表。如：开两个会话，两个事务，并且都不commit，该表有主键，两个会话修改同一条数据，第一个会话update执行后，第二个会话的update是无法执行成功的，会进入等待状态，但是如果update别的数据行就可以成功。再例如：开两个会话，两个事务，并且都不commit，并且该表无主键无索引，那么第二个会话不管改什么都会进入等待状态。因为无索引的话，整个表的数据都被第一个会话锁定了。 间隙锁（gap lock）MySQL默认事务隔离级别是可重复读，这个隔离级别为了避免幻读现象，引入了这个间隙锁，对索引项之间的间隙上锁。 Next-key锁（Next-key lock）Next-key锁实际上是Record锁和gap锁的组合。Next-key锁是在下一个索引记录本身和索引之前的gap加上S锁或是X锁(如果是读就加上S锁，如果是写就加X锁)。默认情况下，InnoDB的事务隔离级别为RR，系统参数innod ...

在数据库里面存储一些结构化数据12345678910111213141516171819202122232425class JSON(TypeDecorator): """ Json String Field """ impl = Text def process_bind_param(self, value, dialect): if value is None: return value elif isinstance(value, (dict, list)): return json.dumps(value) else: raise ValueError("unsupported value type") def process_result_value(self, value, dialect): if value is None: ...

for updateSQLAlchemy 的 Query 支持 select … for update / share 12session.Query(User).with_for_update().first()session.Query(User).with_for_update(read=True).first() 完整形式 1with_for_update(read=False, nowait=False, of=None) read 是标识加互斥锁还是共享锁. 当为 True 时, 即 for share 的语句, 是共享锁. 多个事务可以获取共享锁, 互斥锁只能一个事务获取.有”多个地方”都希望是”这段时间我获取的数据不能被修改, 我也不会改”, 那么只能使用共享锁. nowait 其它事务碰到锁, 是否不等待直接”报错”. of 指明上锁的表, 如果不指明, 则查询中涉及的所有表(行)都会加锁. 扩展with_for_update实际对应mysql的 SELECT ... FOR UPDATE 语句, 但是在使用时要注意, 由于InnoDB 预设是 ...

BasicColumn 配置1234567const columns: BasicColumn[] = [ { title: 'yourTitle', dataIndex: 'yourDataIndex', slots: {customRender: 'yourSlotName'}, },]; 页面使用12345<BasicTable @register="register"> <template #yourSlotName="{ record }"> {{ record['yourDataIndex'] }} </template></BasicTable>