1. Sequence a.可以把列定义为自增键。这跟Sql Server类似，跟Oracle不同。 create table person( id int unsigned not null auto_increment, primary key(id) … ) 和sql server一样，插入数据时不必指定自增键的值 b.id最大的记录删除后，重新插入的数据的id是多少？ 这个答案跟mysql的存储引擎有关。 i. 对于bdb引擎，新的id = 现有id的最大值 + 1; 如果刚删除的最大id=8, 当前的id最大值=7, 则新的id = 7 + 1 =8 ！ 也就是说，id =8 被重复使用了! ii. 对于MyISAM和InnoDB引擎，则可以保证id不会被重用 …
mysql技巧杂烩 (二) 1. 日期与时间 a.若只存日期，则使用"date"类型；若只存时间，则使用"time"类型； 若要存日期+时间，则使用datetime类型(用timestamp也可以，但稍微复杂一些) a2.mysql的日期时间最多精确到“秒”级别 b.string -> date: select str_to_date(‘2012-02-28 18:23:30’, ‘%Y-%m-%d %T’); c. date -> string: select date_format(now(), ‘%Y-%m-%d %T’); d. mysql还提供了很多强大的日期计算函数，此处不述 2. 元数据 a.查看元数据有两大工具：使用SHOW命令 或者 查询INFORMATION_SCHEMA库里的表 b.显示所有数据库：select schema_name from information_schema.schemata; 或 show databases; c.显示库里所有的表： select table_name from information_schema.tables where table_schema=’cookbook’; 或 show tables; d.显示表里所有的字段： i. select * from information_schema.columns where table_schema=’cookbook’ …
1. mysql控制台 a. "select * from t \c " 里的 "\c" 告诉mysql忽略当前的语句 b. 也可以通过Tab键来补全表名、列名 c. 可以不进入mysql控制台，直接在shell状态下执行mysql语句， 如 mysql -e "select * from person" cookbook -u root -p ("cookbook"是数据库名) d. 让查询结果分页：先执行\P /usr/bin/less， 再执行你的查询如 select * from person e. “垂直”地输出结果（每列独占一行）：select * from person \G 2. SQL 方言 a. 拼接函数： concat(c1, c2) …
Feature Branch指的是每开发一个新功能、每修一个bug，都打出一个新的分支，等测试通过后才合并到主干。它的反面是"对所有新功能，大家直接在主干上修改代码“ 个人对Feature Branch的优缺点有一些体会： 优点： 1. 不同feature之间的开发可以彼此隔离，避免了“一损俱损”的风险。比如，如果大家都在主干上开发，一个人不小心提交了错误的代码变更导致了编译错误，会搞得所有人的code base都无法编译。亲身经验表明，这种事情非常浪费时间、损耗士气 2. 隔离了的分支可以独立进行QA测试，时间上不会互相担误。如果大家都在主干上开发，那主干就用于QA测试，也就是说，张三和李四的改动会集成在一起测试， a. 如果张三的改动在测试时发现问题，修改后要重build、重启应用，则李四的改动也意味着要被重启，这会浪费测跟李四有关的测试人员的时间。为了避免这种影响，大家只好约定在每天一两个固定的时间点重build、重启。亲身经验表明，这种做法的效率比较低。 b. 如果张三的改动没测通，李四的改动可能也不准发布，因为测试人员不敢确定张三的错误是否与李四的改动有关 3. 确保未测通的改动不会跟别的改动混在一起或进入主干，避免发布时的“选择性代码合并”问题。如果大家都在主干上开发，在发布时只能选择已测通的改动发出去；由于测通了的改动和未测通的改动混杂在主干分支上，所以合并代码到发布分支时，你要小心翼翼，以保证只合并该合并的代码。虽然现在的版本控制工具很强大，但在处理这类事情时如果遇到复杂的情形，往往还是力不从心，仍须人力来辅助。亲身经验表明，用人力做这种事情比较无聊、费时，而且错误率很高。 （待续） 缺点： 1.每次开发都要新建分支、重建开发环境，比较浪费时间 2.如果每个分支独立测试，则意味着每个分支要占一台测试机器，这要求公司的硬件比较充裕。 3.持续集成的利用率不高。对Feature Branch一般不会持续监控，所以持续集成只能作用在主干上。既然健康的改动才会集成到主干上，所以主干基本上也是健康的，这时持续集成基本上是个摆设。 4.一个分支的大改动要很晚才能集成到另一个分支，导致Big Scary Merge问题(Martine Fowler语)。假如张三的Feature改了很长时间，终于在今天归并到了主干; 而李四已有一个分支在改动，当他第二天把主干集成到自己的分支时（日常集成），由于主干的变动很大，他会发现自己可能会遇到非常多的代码冲突，即Big Scary Merge （待续）
env-specific的配置指的是系统的参数在不同环境下要使用不同的配置，比如jdbc依赖的数据库用户名/密码在开发环境跟在生产环境肯定是不一样的。 Maven为此提供的解决方案是： 1.参数以变量方式定义在resource目录下的配置文件中，如${db.url}, ${db.user}等 2.pom里设定不同环境下的值，并通过"profile"来标识不同的环境 <profiles> <profile> <id>dev</id> <properties> <db.url>jdbc:mysql:dev</db.url> … </properties> </profile> <profile> <id>prod</id> <properties> <db.url>jdbc:mysql:prod</db.url> … </properties> </profile> </profiles> 3.编译时，把配置文件中的变量替换成具体的值 a.首先要打开maven的resource filtering功能 (见maven-resource-plugin的配置说明) b.编译时再指定profile，告诉Maven当前是哪个环境 mvn package -Pdev ======================================== 个人看来，这种解决方案还是相当弱的： 1. 不支持默认值。一个项目可能有几十个env-specific配置，如果不支持默认值，就意味着每个开发人员都得在本地定义这几十个配置；如果某人增加了一个配置并提交到公共分支，另一个人如果不知情，没有定义相应的值，在编译时Maven就无法为新的配置赋值，最后会把${xxx}带到构件中 2. 属性的赋值只能写在pom.xml或settings.xml里，导致很多不便 a.如果写在pom.xml里，由于pom.xml一般纳入了版本控制系统，这意味着张三和李四把pom.xml 签出来后，要再修改其中的dev profile以使它适应本机的配置，然而，这个文件又不准提交。这是出错的温床，也是烦恼之源。 b.如果写在各自的settings.xml里，又很容易出现多项目下，profile命名的撞车问题。比如某人同时开发两个项目，项目Ａ定义了一个叫dev的profile, 项目Ｂ也定义了一个叫dev的profile，但settings.xml里又只能定义一个叫dev的profile，这咋办？
pom.xml 里可以自定义Property,然后通过${}来引用它 <properties> <spring.version>2.5.6</spring.version> </properties> … <dependency> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency> 实际上，maven支持6大类property 1.上面说所的自定义属性 2.Maven内置属性，如${basedir}表示项目根目录 3.POM属性，如${project.artifactId}, ${project.build.sourceDirectory} 4.Settings属性，如${settings.localRepository} 5.Java系统属性，如${user.home} 6.环境变量属性，如${env.JAVA_HOME}
抄自《Maven实战》 版本号 1.3.4-beta-2 该怎么理解？ 1 – 代表“主版本”，表示项目的重大架构变更 3 – 代表“次版本”，表示较大范围的功能增加和变化，但总体架构未变 4.- 代表“增量版本”，一般表示重大Bug的修复或功能的增强 beta-2 – 代表“里程碑版本”，表示当前的开发已经完成了某个里程牌，但还未稳定
Maven中的aggregation与继承是两码事，但一般来说，将aggregation pom用作父pom,也是挺方便的。
继承是为了实现“在父项目里声明，在各个子项目里使用”，比如项目的版本、项目的groupId、依赖等。 下面是项目module-base的pom.xml的片段 <!–module-base将继承module-root–> <parent> <groupId>mvn-module</groupId> <artifactId>module-root</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../pom.xml</relativePath> </parent> <!–这里不必再显式声明groupId和version。项目会自动从父项目中继承–> <artifactId>module-base</artifactId> ======================================== Super Pom java中每个类都是java.lang.Object的子类，maven中每个项目的pom都是Super Pom的子pom. Super Pom是Maven内置的顶级Pom，Maven项目的默认目录结构就是在这里定义的。 ========================================= 对“依赖”的继承是最主要的用处之一。最佳实践是： 1. 父项目的pom.xml通过<dependencyManagement>声明所有会用到的dependency 2. 子项目的pom.xml通过<dependencies>声明所需的依赖。声明中不需要指明所依赖的构件的版本。 说明： 1.为什么要在父项目的pom中集中声明所有依赖？ 因为这样可以保证，对同一个构件，所有子项目都会使用相同的版本。 2.为什么父项目中要用<dependencyManagement>而不直接用<dependencyies> ? 因为如果用后者，其中定义的dependency会被所有子项目继承，子项目在打包时会把这些构件打在自己的包中，即使这个子项目并不需要某些dependency.
Maven项目大了，就要拆成多个小项目。这就是aggregation要干的事。 具体来说，就是要在各个小项目建好之后，再建一个专们用于聚合的项目。在这个项目的pom.xml里声明： <!–此类项目的打包方式必须为pom–> <packaging>pom</packaging> <!–在这里声明小项目–> <modules> <!–module-base, module-app是小项目的目录名–> <module>module-base</module> <module>module-app</module> </modules> 对这个项目执行一下"mvn package", Maven会自动构建小项目module-base 和 module-app 如果执行"mvn package -pl module-base"，则Maven只构建module-base