问题引出:在liftweb中使用logback,使得日志可以使用logback的特性,最重要是可以自定义输出位置
基本配置
scala 2.9.2
lift 2.5.M4
logback-classic 0.9.28
slf4j-log4j12 1.6.1 (建议)
陷进1.class Boot
在def boot中不要设置
Logger.setup=Empty
虽然这样做确实会避免liftweb读取log4j.xml
陷进2.class Boot
不要为boot添加以下特性
trait Config {
val logUrl = LiftRules.getResource("/props/test.default.logback.xml")
logUrl.foreach(x => {
Logger.setup = Full(Logback.withFile(x))
})
}建议1.logback.xml建议放在/resources目录下,分别命名为
default.logback.xml production.default.logback.xml test.default.logback.xml
这样可以通过配置Tomcat中的
-Drum.mode=XXX(test,production)
来使用不同的配置
logback.xml中
<!-- 日志输出级别 -->
<root level="INFO">
<appender-ref ref="FILE_INFO" />
</root>
<root level="WARN">
<appender-ref ref="FILE_WARN" />
</root>
<root level="ERROR">
<appender-ref ref="FILE_ERROR" />
</root>
<root level="DEBUG">
<appender-ref ref="STDOUT" /> </root>
必须包含以下四个等级的输出,否则日志将不会被输出到文件.特别注意不能因为不需要DEBUG而省略
作者：daaoke 发表于2013-5-9 8:50:42 原文链接
阅读：75 评论：0 查看评论
数据库/模型 最佳实践：
模型是很多Django项目的基础。
这是我们挑选的用于模型的第三方包
*South 用来做数据库迁移，这是一个很好用很常见的工具
*django-model-utils to handle common patterns like TimeStampedModel
*django-extensions 它有一个强有里的shell工具来自动装载所有app的模型
基本知识：
*拆分有太多模型的app
如果一个app中有超过20个模型，那么就要把它拆分成小的app了，可能这一个app做的东西太多了。实际操作中，一般每个app的模型不超过5个
*不是必要的情况，不要使用原生的sql
如果可以使用ORM来配置数据库操作，请优先使用。
使用原生SQL使得app的可移植性降低
Django BDFL Jacob Kaplan-Moss says (paraphrased): If it's easier to write a query using
SQL than Django, then do it. extra() is nasty and should be avoided; raw() is great and should be used where appropriate
*在需要的时候增加indexs
我们的习惯是开始不添加index，需要的时候才添加
我们考虑增加index的情况：
*index使用非常频繁，百分之10~25的查询中都需要它
*我们可以通过测试来衡量生成的indexs是否提高了查询性能
*有真实的数据或者接近真实的数据，我们可以使用index来分析
*小心模型继承
Django提供了3中模型继承的方式：abstract base classes,multi-table inberitance ,proxy models
注意：Django Abstract Base Classes!= Python Abstract Base Classes
避免 Multi-Table 继承
模型继承的案例：The TimeStampedModel 时间戳模型
# Code taken with permission from Carl Meyer's
# very useful django-model-utils
from django.db import models
from django.utils.timezone import now
from django.utils.translation import ugettext_lazy as _
class AutoCreatedField(models.DateTimeField):
"""
A DateTimeField that automatically populates itself at
object creation.
By default, sets editable=False, default=now
"""
def __init__(self, *args, **kwargs):
kwargs.setdefault('editable', False)
kwargs.setdefault('default', now)
super(AutoCreatedField, self).__init__(*args, **kwargs)
class AutoLastModifiedField(AutoCreatedField):
"""
A DateTimeField that updates itself on each save() of
the model.
By default, sets editable=False and default=now.
"""
def pre_save(self, model_instance, add):
value = now()
setattr(model_instance, self.attname, value)
return value
class TimeStampedModel(models.Model):
"""
An abstract base class model that provides self- updating ``created`` and ``modified`` fields.
"""
created = AutoCreatedField(_('created'))
modified = AutoLastModifiedField(_('modified'))
class Meta:
abstract = True #声明为抽象基类
测试：# flavors/models.py from django.db import models from model_utils import TimeStampedModel class Flavor(TimeStampedModel): title = models.CharField(max_length=200)Django的模型设计：
*从标准化开始，一定要熟悉，datebase normalization
*在没标准化之前缓存
*只有特殊需求下才可以不遵守标准
什么时候使用null 和 blank
在设置一个字段的属性的时候有 null=True and blank=True的选项，默认都是False的
具体建议请参照书中表格：ex 文本型字段 使用blank=True
模型控制器：Model Managers
可以自己定制 小案例：
from django.db import models from django.utils import timezone class PublishedManager(models.Manager): def published(self, *args, **kwargs): qs = self.get_query_set().filter(*args, **kwargs) return qs.filter(pub_date__lte=timezone.now()) class FlavorReview(models.Model): review = models.CharField(max_length=255) pub_date = models.DateTimeField() # add our custom model manager objects = PublishedManager()注意：1 在模型继承中，抽象基类的自定义模型控制器会遗传给孩子，实体类不会
2 不同的model class中使用时要特别小心
IP首部
IP协议是TCP/IP协议族中最核心的协议，所有的TCP、UDP、ICMP、IGMP数据都是以IP数据报格式传输的。
IP提供不可靠、无连接的服务。
不可靠：不能保证IP数据报能成功到达目的地。可靠性由上层（如TCP）提供。
无连接：IP并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。IP数据报可以不按发送顺序接收。
IP数据报格式：
IP数据报用bit endian字节序传输。
（1）4位版本：表示版本号
（2）4位首部长度：首部占32bit字的数目。最大为15*32/8=60字节。普通IP数据报该字段值是5，也就是首部为5*32/8=20字节。
（3）TOS：3bit优先权字段（已忽略），4bitTOS子字段，标识最小时延（Telnet，Rlogin），最大吞吐量（FTP），最高可靠性（SNMP），最小费用（NNTP，用户网络新闻）。4bit中只能置其中1bit。4bit均为0表明一般服务。
（4）16bit总长度字段：整个IP数据报的长度，单位是字节。最长可以是65535字节，但大多数链路层会对它进行分片。
（5）16位标识：唯一标识主机发送的每一分数据报，每发一份值加1，因为IP是无连接的，所以这个值在数据报重组时应该要被用到。
（6）TTL：设置了数据报可以经过最多的路由器数。每经过一个路由器就减1，到0就丢弃。
（7）先将检验和字段置0，对首部中美16bit进行二进制反码求和，结果存在检验和字段中。当接收到一份数据报时，同样对首部中没16个bit反码求和，若计算结果全1则检验正确。否则丢弃该数据包。ICMP，IGMP，UDP和TCP采用相同的检验和算法。
IP路由选择
概念上，IP理由选择是简单的，若源主机和目的主机直接相连或者在一个共享网络上，就直接将IP数据报送到目的主机，否则发往默认的路由器，由路由器转发。
大多数用户系统都可以配置成路由器。
IP层在内存中有一个路由表，当收到数据报并要对它进行发送时，要对表进行搜索。当数据报来自某个网络接口时，IP会检查目的地址是否为本机地址之一或者是广播地址，若是，则数据报被送到由IP首部协议字段规定的协议模块中处理。若不是，则若主机IP层被设置为路由器功能，转发数据报，否则丢弃。
IP路由表每一项都具有：目的IP地址，下一站路由地址，标志，为数据报传输指定的网络接口
IP路由器完成功能（按序）：
1. 搜寻路由表，找与目的地址完全匹配的表目。
2. 搜寻路由表，找与目的网络号匹配的表木目。
3. 搜寻路由表 寻找默认表目。
若上面的步骤都没有成功则返回“主机不可达”或“网络不可达的错误”。
为一个网络指定一个路由器而不需要为每个主机指定一个路由器，这样可以缩小路由表的规模。
数据报中的目的IP地址始终不会发生变化，每个链路层可能具有不同的数据帧首部，而且链路层的目的地址始终指下一站的链路层地址。
子网寻址
由于A类B类地址分配了太多的空间给主机，将主机号再分成一个子网号和一个主机号，用子网掩码表明哪个是网络号，哪个是主机号。掩码是32bit值，为1的指定是网络号，0的是主机号。