dingo API: A RESTful API package for the Laravel framework
最近好像是支持 Lumen 了，用來(lái)做 API 應(yīng)該很合適。

if ($('#data-table').hasClass('dataTable')) {
    var oldTable = $('#data-table').dataTable();
    oldTable.fnClearTable(); //清空一下table
    oldTable.fnDestroy(); //還原初始化了的dataTable
    $('#data-table').empty();
}

墨菲定律只要有可能出錯(cuò)，就一定會(huì)出錯(cuò)，不管它的概率有多小。

不能連續(xù)出現(xiàn)，單機(jī)服務(wù)。舉個(gè)例子，假如你使用 自增ID 在加 System.nanoTime() 組成一個(gè) long 類型數(shù)字（是字符串形式連接，而不是加法）。這個(gè)ID就不會(huì)重復(fù)了，因?yàn)?自增ID 一定不會(huì)重復(fù)。

建議使用官方鏡像,或者mariadb可能是更好的選擇
https://store.docker.com/imag...

你和后臺(tái)是一個(gè)局域網(wǎng)的話,先ping一下他的ip,看看通不通,再把你那個(gè)請(qǐng)求的路徑放到瀏覽器直接打開,報(bào)405接口是通的,跨域是他后臺(tái)沒有設(shè)置請(qǐng)求頭,報(bào)403是網(wǎng)關(guān)沒穿透,需后臺(tái)設(shè)置,還報(bào)404的話是他的ip根本不通,配置完代理記得重啟項(xiàng)目

停掉其他服務(wù)，還有命令啟動(dòng)命令是‘mongo’ 打錯(cuò)了；

主外鍵類型不一致，查看下主鍵和外鍵的數(shù)據(jù)類型和設(shè)置的長(zhǎng)度是否一致？

MyISAM 因?yàn)樗奈募撬饕募?和 數(shù)據(jù)文件存的，而且索引文件存的是地址，所以基本上是用于頻繁的查詢的；
InnoDB 因?yàn)槭谴娴氖菙?shù)據(jù)文件，索引也都放在一起，而且又擁有事務(wù)，所以它幾乎用于增刪改操作，當(dāng)然，如果數(shù)據(jù)量小的話，也可以存于innodb引擎的，比如10W內(nèi)；；然后其他的就根據(jù)你業(yè)務(wù)上的需要而進(jìn)行調(diào)整而選擇哪個(gè)引擎了。

使用MongoDB的第一件事情就是忘掉關(guān)系模型，充分利用反范式、冗余來(lái)達(dá)成最高的讀寫效率。你已經(jīng)發(fā)現(xiàn)了現(xiàn)在的數(shù)據(jù)模型不好用，為什么不換個(gè)思路來(lái)解決問題？
決定數(shù)據(jù)模型的是你需要怎么使用這些數(shù)據(jù)。在不知道你打算怎么用這些數(shù)據(jù)的前提下，以下是一些按照常理的推測(cè)。
現(xiàn)在涉及的實(shí)體有3個(gè)：

• teacher
• student
• class

其中:

• teacher:class = 1:n
• class:student = 1:n

對(duì)于1:n的情況，最常見的做法是把1冗余到n。比如學(xué)生可以是：

{
    _id:ObjectId(123456789...),
    name:'zhangsan',
    age:20,
    class: {
        classId: ObjectId(123456789...),
        number:10,
        // 其他常用字段
    }
}

當(dāng)然你也可以不要class的詳細(xì)信息，畢竟一個(gè)班的學(xué)生只用查一次班級(jí)信息。

{
    _id:ObjectId(123456789...),
    name:'zhangsan',
    age:20,
    classId: ObjectId(123456789...)
}

用的時(shí)候是不是會(huì)方便一些？
沒錯(cuò)，冗余有可能會(huì)造成數(shù)據(jù)不一致，但是你真的會(huì)這么在乎一致性嗎？通常的回答是不會(huì)。
比如如果班級(jí)信息如果要修改怎么辦？那就會(huì)造成每個(gè)學(xué)生的班級(jí)信息都更新一遍，修改時(shí)壓力會(huì)比較大操作比較復(fù)雜。但是別忘了你的系統(tǒng)大部分壓力是來(lái)自讀而不是寫。班級(jí)修改的概率有多大？可能幾個(gè)月不見得有一次。但是讀班級(jí)的概率有多大？可能每天就有好多次。比較一下孰輕孰重不言而喻。

綜上，使用MongoDB時(shí)不要用范式來(lái)約束自己，從性能，易用性來(lái)考慮就可以了。

1. 開分支
2. 按模塊做重構(gòu)
3. 測(cè)試
4. 合并

重復(fù) 2-3

SELECT count(*) FROM test GROUP BY DATE_FORMAT(time ,'%Y-%m-%d');

如果只要某個(gè)范圍內(nèi)的天數(shù)可以在加一個(gè)
where
time>='startday' AND time<='endday'

lz今天再次調(diào)試的時(shí)候, 因?yàn)殚_始出現(xiàn)了一個(gè)Servlet沒有找到, 就順手clean了下Tomcat和項(xiàng)目的緩存, 然后再次調(diào)試, 居然詭異般的好了...
哎 , 無(wú)心插柳柳成蔭, 里面的機(jī)制太讓人費(fèi)解了.

比如下面的帖子列表中的作者名字和留言里的作者名字，都需要改成備注的。

這種情況下不報(bào)異常就是成功

py不熟，給思路吧。

SVG和Canvas的區(qū)別，我覺得前者更偏重于聲明式（或者可以說(shuō)類似于HTML標(biāo)簽），而后者則更多的是命令式的（對(duì)應(yīng)Javascript語(yǔ)言）。這就導(dǎo)致了它們?cè)趹?yīng)用上，SVG使用固定/已有圖像、以及相對(duì)“固化”的動(dòng)畫效果時(shí)，會(huì)更有優(yōu)勢(shì)一些；而Canvas則足夠動(dòng)態(tài)，適用于一些需要復(fù)雜邏輯控制（舉個(gè)例子，比如繪制根據(jù)聲波變化的連續(xù)的正弦曲線）或者在2D/3D或者需要復(fù)雜圖形學(xué)參與的場(chǎng)合。至于矢量還是位圖，由于它們都具有操作位圖的能力，所以其實(shí)都無(wú)所謂。
題目中這個(gè)我覺得還是SVG更適合，前邊說(shuō)了SVG和HTML相對(duì)的會(huì)比較親和，所以如果不是特別大的文件，去掉頂部的XML和Doctype聲明之后，是可以直接嵌入到HTML之中的，比如我之前寫過的一個(gè)H5里，有幾張小圖都是單獨(dú)出現(xiàn)的，我為了避免逐個(gè)去定位，就把它們直接寫到了一個(gè)SVG容器里：

<svg id="awardOuter" version="1.1" baseProfile="full" width="540" height="541" xmlns="http://www.w3.org/2000/svg">
    <defs>
        <g id="first" width="150" height="175">
            <image xlink:href="xxx.png" x="0" y="35" width="150" height="75"></image>
            <text font-size="20" fill="white" x="75" y="130" text-anchor="middle">第一</text>
        </g>
        <g id="second" width="150" height="175" transform="rotate(120 75 87)">
            <image xlink:href="yyy.png" x="0" y="35" width="150" height="75"></image>
            <text font-size="20" fill="white" x="75" y="130" text-anchor="middle">第二</text>
        </g>
        <g id="third" width="150" height="175" transform="rotate(240 75 87)">
            <image xlink:href="zzz.png" x="0" y="35" width="150" height="75"></image>
            <text font-size="20" fill="white" x="75" y="130" text-anchor="middle">第三</text>
        </g>
    </defs>
    <image xlink:href="img/temp.png" x="0" y="0" width="540" height="541"></image>
    <use xlink:href="#first" x="195" y="20"></use>
    <use xlink:href="#second" x="334" y="264"></use>
    <use xlink:href="#third" x="50" y="264"></use>
</svg>

這段我是直接寫到HTML里的，可以看到SVG主標(biāo)簽上其實(shí)就只有SVG命名空間（xmlns="http://www.w3.org/2000/svg"）、版本信息（版本號(hào)version="1.1"和相應(yīng)的語(yǔ)言集baseProfile="full"），然后再加個(gè)寬高就可以了（當(dāng)然如果有復(fù)雜縮放可以加上SVG視口屬性），定位直接用CSS定位就行。矢量的話也是一樣的思路，看你已經(jīng)寫了Demo，可以套進(jìn)去試試。

pg如果不支持分區(qū)函數(shù)的話，就多關(guān)聯(lián)幾次表吧，如：

select id, name, time, max(value)
from t inner join (
select id, name, max(time) as max_time
from t
group by id, name
) t1 on t.id = t1.id and t.name = t1.name and t.time=t1.max_time
group by id, name, time

thinkphp 查詢寫法
$where['g.preic'] = array('between','10,20');
$where['ge.level'] = 60;
$where['ge.money'] = 1000;
M('goods')
->alias('g')
->join('left join goods_ext ge on ge.goods_id = g.goods_id')
->where($where)
->select();

@leftstick
向你請(qǐng)教一個(gè)問題。
我有個(gè)用戶表，user----userId
有個(gè)話題表，topic ----topicId
現(xiàn)在做一個(gè)關(guān)注表，就是用戶關(guān)注了某一些話題：like
目前我的解決方案是，額外建立一張表

const like = Model.define('like', {
  userId: {
    type: sequelize.INTEGER,
    allowNull: true,
  },
  topicId:{
    type: sequelize.INTEGER,
    allowNull: false
  }
}, {
  tableName: 'like',
  timestamps: true,
  updatedAt: false
})

like.hasMany(Topic,{foreignKey:'topicId',sourceKey:'topicId'})

這是我查詢某個(gè)人的關(guān)注話題，并且從topic中獲取話題的詳細(xì)信息。比如title，描述等等。。。

await LikeModel.findAll({
        include:{
          model:TopicModel,
        },
        attributes:{exclude:['id','createdAt']}
      }).then(res=>{
        console.log(res)
        ctx.body = res
      })

得到的結(jié)果

[
    {
        "userId": "1",
        "topicId": 1,
        "topics": [
            {
                "topicId": 1,
                "title": "1212",
                "des": "2332"
            }
        ]
    },
    {
        "userId": "1",
        "topicId": 2,
        "topics": [
            {
                "topicId": 2,
                "title": "1212",
                "des": "2332"
            }
        ]
    }
]

但我想要的數(shù)據(jù)是，關(guān)注的話題套入到topics這個(gè)數(shù)組中。。。

我想請(qǐng)問在這種情況如何解決呢？？
2，或者我建立的表關(guān)聯(lián)是否用如下建立

User.belongsToMany(Topic,{through:'like',foreignKey:'unionId',otherKey:'topicId'})
Topic.belongsToMany(User,{through:'like',foreignKey:'topicId',otherKey:'unionId'})

多對(duì)多，建立聯(lián)系，怎么操作這數(shù)據(jù)呀？

如果是當(dāng)前日期，用SYSDATE系統(tǒng)變量就可以了。

SELECT SYSDATE FROM dual;

如果是字符串轉(zhuǎn)日期，用to_date函數(shù)，如：

SELECT to_date('2017-12-05 08:00:00', 'yyyy-mm-dd hh24:mi:ss') FROM dual;

因?yàn)锳dvisor這個(gè)接口有PointcutAdvisor和IntroductionAdvisor兩個(gè)子接口和一個(gè)靜態(tài)內(nèi)部實(shí)現(xiàn)類PrototypePlaceholderAdvisor，所以這樣判斷。