< Mysql left join 重复多条记录问题 >
mysql left join 后存在多条重复的数据记录,问题出在了left join 中存在一对多的关系。而上网上一般的解决方法是使用Group By 去重,但使用Group By一般会引发一些问题,比如排序。 在我们要使用分页查询的时候使用Group By会出现很多问题,而且5.7比使用Group By也有些问题,需要配置一些东西。 所以我觉的在能不用Group By的时候尽量不要用Group By。 最好的解决办法就是找出一对多的那个表,先把多的那个表使用Group By合并,如要要排序记得,先排序后再Group By, 把一对多的表子查询为一堆一后再进行left  join就不会出现重复的数据了
2019-03-12
< mysql group by 和 order by 一起用失效 >
我自己写了一个前端错误监控系统。 前端有各种报错,后台就会自动发邮件通知、 这里就会遇到同一个错误可能很多人遇到,或者同一个人遇到很多次。 这样同一个错误就会有很多次报错。 当管理员进入后台时,看到很多同一个错误的报错,这很明显不人性化。 于是我就设计成,同一个错误的合并,只显示最新那个。 一开始sql写法为 SELECT * from `errors` GROUP BY `title`,`msg`,`category`,`level`,`appId` ORDER BY `createdAt` DESC 发现同一个错误是合并了,但是 ORDER BY 并没有生效,合并后的错误不是最新的一条错误而是最早的一条。于是查了资料发现,GROUP BY 没有排序功能,默认取合并时的第一条。于是就想到了,先排序完再合并就好了,于是有下面代码: SELECT * FROM (SELECT `errors`.*,`apps`.name from `errors` LEFT JOIN `apps` ON `errors`.`appId`=`apps`.`id` WHERE `app
2019-03-05
< 使用HTTPCODE替换自定义CODE >
| 前言:现在的开发基本都是前后端分离的项目,既解放了前后台各自的生产力(后台专注写业务给出数据就行,再也不用管前端UI的事。前台专注于写UI拿数据就行,再也不用跑后台服务,不用打开eclipse了)又可以一套代码兼容多个项目:APP,网页,微信,微信小程序等。 但在开发的过程中发现了,现在后台普遍用了自定义code去判断接口的成功失败信息。而http code则变成鸡脖,除非是服务器蹦了之外,其他一律返回200成功。为什么会有这个现状呢?具体不是很了解啊,据说是以前IE上有些http code报错会导致IE一些问题。不知道是不是,知道的可以给我科普下。 而在开发中使用自定义code也并没有什么问题,例如我们的项目一般接口返回的response信息完整结构: { data:{ data:{ userList:[ {id:1} ] }, rcode: 300, message: "操作成功" }, engine:'.....', headers:{//....}, request:{//....}, status:200, stat
2019-01-24
< Frontend-Sniper/前端错误上报系统 >
前端错误监控系统服务端 其实线上已经有很多监控系统了,例如fundebug [https://www.fundebug.com/]。试用了一下还是挺不错的。 可惜都是收费的,免费的只能创建一个项目,收费也不便宜。 对于一些小公司来说很难花钱去搞,而且对小公司来说功能也不需要太复杂。 一些js的报错和接口报错就可以大大加快bug的修复,和预知bug。(当上级和测试都还没发现时) 所以我还是写这么个系统,是从自身需求出发吧。功能可以慢慢完善。 现在初期只实现了简单的js和接口资源报错。后期会加入UA和用户等信息以完善错误信息追踪错误。 对服务端还是新手所以代码质量....graphql也是试手。 但好在错误监控系统一般内部人使用,独立不影响线上项目和用户。所以大胆地使用吧。 项目集 * 服务端 frontend-sniper-server [https://github.com/callmesoul/frontend-sniper-server] * 管理后台 frontend-sniper-admin [https://github.com/callmesoul/fr
2018-09-12
< Flex 布局问题汇总 >
flex布局使用起来很方便 而且现在的浏览器也基本支持了 大家可放心用起来。 但用了flex总会有一些小问题 这里总结下再使用flex时遇到的问题: flex下 input 宽度无法自适应: <div class='flex'> <input class='flex1'> <button>提交</button> </div> 以上代码在有写浏览器上input宽度不能自适应,导致了input和button宽度固定,如果button的自多点就会超出了父div的宽度了。 解决方法: * 添加min-width:0;网上说的,但试了下并不行 * 添加div包裹即可(推荐) <div class='flex'> <div class='flex1'><input style='width:100%'></div> <button>提交</button> </div> flex 下text-overflow: ellipsis;不生效
2018-09-11
< video >
* ios系统下,视频播放默认全屏播放 解决方法:加上x5-playsinline="" playsinline="" webkit-playsinline=""
2018-08-01
< REM >
- 自适应更改html font-size js designSize=640 为设计稿大小 htmlFontSize=100为当设计稿为640px时html font-size为100px (建议默认100,因为好换算,10也可以,但pc有些浏览器会不支持12px以下字体,所用100最安全) 此时1px=0.01rem; (function(doc, win, designSize,htmlFontSize) { var docEl = doc.documentElement, isIOS = navigator.userAgent.match(/\(i[^;]+;( U;)? CPU.+Mac OS X/), dpr = isIOS ? Math.min(win.devicePixelRatio, 3) : 1, dpr = window.top === window.self ? dpr : 1, //被iframe引用时,禁止缩放
2018-07-20
< 使用gitalk 代替其他第三方评论插件 >
前言 第三方评论插件已经死得差不多了,从一开始多说到后来的网易云跟帖,最后剩下了畅言。最近畅言为了活下去,也退出了广告,让用户体验更差了。本来用户体验就不咋地。可惜碍于找不到其他更好的代替者就只好将就一下了。 知道今天找到gitalk,坚定不移地把畅言给换了。 关于gitalk Gitalk 是一个基于 GitHub Issue 和 Preact 开发的评论插件。 * 使用 GitHub 登录 * 支持多语言 [en, zh-CN, zh-TW, es-ES, fr, ru] * 支持个人或组织 * 无干扰模式(设置 distractionFreeMode 为 true 开启) * 快捷键提交评论 (cmd|ctrl + enter) Readme [https://github.com/gitalk/gitalk/blob/master/readme.md] 在线示例 [https://gitalk.github.io/] 使用 1. 在需要插入评论的地方给个占位<div id="gitalk-container"></div> 2. 接
2018-07-13
< 常用正则表达式 >
不能为空 /\S/ 移动号码 ^134[0-8]\\d{7}$|^(?:13[5-9]|147|15[0-27-9]|178|1703|1705|1706|18[2-478])\\d{7,8}$ 联通号码 ^(?:13[0-2]|145|15[56]|176|1704|1707|1708|1709|171|18[56])\\d{7,8}|$ 电信号码 ^(?:133|153|1700|1701|1702|177|173|18[019])\\d{7,8}$
2018-07-13
< 浅谈GraphQl >
什么是Graphql? 简单来说就是facebook出的,来替换restful api的api方案。可由前端定制所需字段后台自动返回定制字段的api方案。更详细的自行百度。 GraphQl趋势? 先说优点吧: 1. 不吃后台语言,因为不是一门编程语言,无论太后用什么语言都可以实现。 2. 类中间层,不影响原有的代码和restful api。 3. 最重要的就是它的灵活行了,可以前端可定制字段。 单单这三点就足以看出了GraphQl很大可能就是已有主流的api方案。 但为什么发布都几年了还不死很普及? 个人总计觉得最重要的原因就是GraphQl后台部分编写: 你叫一个学后台语言Java后者php的人去学习下GraphQl,然后编写GraphQl的后端相关。 后台开发者一般都是看都没看GraphQl,就拒绝的了。 所以一般的公司很难去折腾,只有facebook,github类的强技术公司才用起了。 但好东西始终是好东西,不会因为一些原因而不前进的。 问题是怎么解决这个阻碍。 所以个人觉得GraphQl的普及依赖于大前端时代! 什么是大前端时代? 其实现在也差不
2018-03-13
00:00
00:00