（Photo by Goran Ivos on Unsplash）
今天使用Tushare获取个股的bar数据时，遇到这样一个问题。获取数据写入MySQL后，表里面date字段显示带有“00:00:00”格式，而且字段类型为datetime，如下图所示。
这或许没有什么问题，但和我预期的结果有差异，我预期date字段的数据类型是date，不希望它是datetime。并且，我不想date字段的值里面带有“00:00:00”这些内容。
排查原因，最后发现是Tushare包里面bar函数，获取到数据后，通过Pandas.to_datetime函数，将日期字段转换为带“00:00:00”格式的日期值。
见trading.py程序里面第861行，如下所示。
|
|
（Photo by Nghia Le on Unsplash）
上周五遇到pandas.DataFrame.to_sql写入Mysql数据库报错1170问题（详见：pandas.DataFrame.to_sql写入MySQL报错1170），卡了我一整天；周六联系Tushare作者米哥，在用户交流群里，发帖求助，米哥给了一些建议，我尝试了一下，报错依然存在；周日查SQLAlchemy Reference，在想是不是哪个参数没用对，看得要吐血了还是没有眉目；晚上和一个朋友聊天，他说他现在只用PostgreSQL，完全不用MySQL……
这句话给了我灵感，我把数据库换成PostgreSQL，结果会怎样？
上午来公司，安装PostgreSQL，熟悉语法，配置完后，拿原来代码直接一跑，我靠，直接成功。PostgreSQL没有像MySQL那样，创建索引时要求TEXT类型必须指定长度，我心里暗爽，即使MySQL报错1170问题无法解决，我可以用PostgreSQL继续完成我的股票分析大业啊。
（Photo by Fredrick Kearney Jr on Unsplash）
今天在使用pandas.DataFrame.to_sql这个接口，将Tushare获取的一个DataFrame写入MySQL时，出现如下报错。
PGM:writedb:write_records_into_mysql:error: (_mysql_exceptions.OperationalError) (1170, “BLOB/TEXT column ‘code’ used in key specification without a key length”) [SQL: u’CREATE INDEX ix_k_data_code ON k_data (code)’] (Background on this error at: http://sqlalche.me/e/e3q8)
这个错误在创建MySQL表时很常见，当键值字段是变长的BLOB或TEXT类型，MySQL引擎无法生成索引。
很遗憾，尽管知道原因，也尝试过几乎所有可行的办法，但就是没法解决。很无奈，编程工作就是如此，半年前的代码，核心程序不变，搁现在重构一下，就跑不通了。
心情灰暗了一整个上午，下面是报错详细内容。
最近在将半年前写的Python股票分析程序重构，打算写一个标准的Python包出来。write_records_into_mysql是所有程序写入MySQL的接口，它有两个必输参数，分别是df和table_name；三个默认参数，分别是conn、if_exists、dtype。
其它细节不贴，一眼就能看明白，这个函数主要作用是调用pandas.DataFrame.to_sql接口，将df写入数据库。to_sql接收的参数和write_records_into_mysql接收的参数其实是一样的，乍一看这里好像存在重复封装，为什么不直接调用to_sql写数据库，而要采用调用write_records_into_mysql的方式？这是一个好问题。
前两天整理使用Python爬虫下载电子书一文时，提过要给爬虫程序增加缓存处理。后面花了2天时间把Redis用法摸熟，然后在Mac上配置好了Redis环境。搭好环境后，发现那个爬虫程序其实非常简单，使出Redis有点大材小用，于是把Redis用在缓存股票数据上面，结果效果非常好。
关于Redis的缓存处理，我参考了陈皓老师缓存更新的套路文中提到的“Cache Aside Pattern”模式，来进行缓存设计，下面直接引用他博客里面的内容，非常受启发。
- 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从cache中取数据，取到后返回。
- 更新：先把数据存到数据库中，成功后，再让缓存失效。
（Photo by Alex Vasey on Unsplash）
昨天提交代码到GitHub仓库时，不小心把敏感信息（登陆账号和登陆密码）提交了上去。发现后立马在GitHub上修改源代码，将里面的敏感信息删除，删除后查看这个文件的历史操作记录，包含敏感信息的历史版本仍然存在。
以为删除文件可以解决这个问题，然而并非如此，把整个文件删除后，历史记录并没有被清空，反而增多一条删除文件的操作，前面两步操作的记录仍然存在。
网上搜了一大圈解决办法，最终找到的解决办法如下。