本人还是个菜鸟，下面是我的经验之谈，能解决一些问题，有不对的地方，敬请斧正。
我的是CentOS6.3+MySQL5.1.57。
重启了一次服务器后，使用> mysql -u root -p登陆是出现下面的错误：
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
于是，我检察mysql状态：
> /etc/rc.d/init.d/mysqld status
显示stop，未运行。
>/etc/rc.d/init.d/mysqld restart
Stopping mysqld: [ OK ]
MySQL Daemon failed to start.
Starting mysqld: [ FAILED]
>ps -ef | grep mysql
root 28221 27474 0 14:18 pts/0 00:00:00 grep mysql 只有这一条
至此，我可以确定，mysql无法启动。
我开始排错，首先发现/tmp/mysql.sock不存在
>vim /etc/my.cnf
socket=/var/lib/mysql/mysql .sock
/var/lib/mysql/mysql .sock同样不存在
>find / -name mysql.sock
显示为空，未查询到mysql.sock文件，mysql.sock文件丢失了。
我看网上有人说mysql.sock套接字文件可以简单地通过重启服务器重新创建得到它，
>init 6 重启命令
重启后发现错误还是那样，没有任何改变，mysql.sock重启服务器未自动生成。
接下来了解到mysql.sock是一个临时文件,在mysql启动时会自动生成,我的服务器未启动，自然就没有mysql.sock文件。
我尝试安全启动模式，mysqld_safe试图通过工作目录找到服务器和数据库，但mysqld_safe还是失败。
>mysqld_safe &
Starting mysqld daemon with databases from ....../mysql/var
STOPPING server from pid file .......pid
130802 15:17:11 mysqld ended
各种命令尝试无效的情况下，我开始了本次最大的收获----学会看错误日志。
在错误日志中，启动失败的原因极为明显，file ‘./mysql-bin。000004’ not found，failed to open！
mysql开启了bin日志功能，到数据库根目录查看该文件是存在的，可能是文件权限的问题。
>chown -R mysql:mysql /....../mysql/var
>mysqld_safe &
>/etc/rc.d/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK]
成功启动了！~
此时mysql.sock文件出现了，在/var/lib/mysql/mysql .sock。如下图所示，以”s”开头的文件都是socket文件。
> mysql -u root -p
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
/tmp/mysql.sock
解决这个错误很简单，因为/tmp/mysql.sock不存在，用这样的方法:
>ln -s /var/lib/mysql/mysql .sock /tmp/mysql .sock
以”l”开头的文件是软链接文件。或者可以通过修改/etc/my.cnf文件来修正它。
成功解决了！~
就是这样一个问题折腾了我这么久，错误日志让它无所遁形。查看错误日志可以明确问题所在，而不是像我之前那样盲目的找错。
俗话说授人以鱼不如授人以渔，学会查看日志，你也可以方便快捷的解决问题了。
错误使人进步，我与这个错误斗争了四个多小时，对linux的“一切皆文件”这句话有了更深的了解，对我学习文件系统管理（目录树）有很大的帮助，让我的思维真正的从windows操作系统转向成linux系统。并最终解决问题，很有成就感，我喜欢这种感觉。
希望能对阅读的你有所帮助，谢谢！~
本文链接：http://www.cnblogs.com/super-lucky/p/superlucky.html，转载请注明。
使用数据库元数据为Entity Framwork实体生成注释
众所周知Entity Framwork自动生成的实体上没有注释。
img1
没错，我使用的是Entity Framwork的各种应用模式中的数据库先行模式。本文不讨论Entity Framwork的哪种应用模式更好的问题而是讨论Entity Framwork提供的T4模板没有生成实体注释的问题。
通常架构数据库的时候会书写描述架构的元数据。如
img2
SqlServer把这些元数据存储在哪里我不关心。但是从下图可以发现貌似这种元数据是个键值对结构。并且该类元数据被称作Extended Properties
img3
通常数据库会以数据库爱好的方式提供操作数据的接口。操作这里的Extended Properties类别的元数据的接口是什么呢？是下面一个系统元数据函数和三个系统存储过程：
img4
img5
img6
img7
这四个接口刚好完成我们所需要的对Extended Properties类别元数据的CRUD操作。可惜，Entity Framwork的实体数据模型中并不包含这类属性。虽然这类元数据与ORM无关但是它们对我们的代码有利，如果能把这类元数据以注释的形式加到实体类代码上的话。
为了确认Entity Framwork的实体数据模型上不包含这类元数据，现在然我们以数据库优先的方式创建一个Entity Framwork项目，随便找一个数据库建好了后从数据库更新元数据
img8
在点击“Update Model From Database”之前开启SqlServer Profiler程序
img9
通过监视Entity Framwork更新元数据的sql代码可以发现Entity Framwork并没有查询Extended Properties类别的元数据。上面说了这类元数据与ORM这件事情无关，所以干正经事的Entity Framwork根本不需要查询这类元数据。但是我们想要利用数据库中的Extended Properties元数据为实体代码自动添加注释，这件事对于我们来说是正经事。想要利用实体数据模型上的元数据为实体代码添加注释的道路是难以走通了因为Ef都根本没去查这类元数据。
那么，我们自建模型。通过监视Entity Framwrok从数据库更新元数据的Sql代码我们领会到了SqlServer元数据数据访问方面的知识。研究发现为生成实体数据模型元数据Entity Framwork查询下如下结构的四种数据：
img10
上图四种元数据分别对应SqlServer的表、视图、表列和视图列。当然这四类元数据现在表现为四张数据库视图这是经过我封装好了的。我们将这四张视图作为提供元数据的“接口”。没错就是“接口”，谁规定过接口必须是C#中的interface关键字定义的结构？接口是契约，这四张视图就是我们的数据库契约，现在我建的每个数据库都实现了这个接口，它们都具有这四张视图。这四张视图是通过参考Entity Framwork获取元数据的Sql语句建立的。这些Sql查询太过复杂，尤其查询表列和视图列的元数据的查询语句复杂的让人难以入眼，下面只贴一个表视图吧：
img11
有了上面四张视图，再加上三个系统存储过程sys.sp_addextendedproperty、sys.sp_updateextendedproperty、sys.sp_dropextendedproperty和一个系统元数据函数::fn_Listentendedproperty，如果这些知识都是我们熟悉的或者留意过的则大部分人可以在头脑中有一个大致的解决方案了。但作为善终，本文还得继续。废话少说，下面开始架构和编码。
讨论到现在发现一直都是在围绕这数据库说事，可见数据库这个概念很重要，所以我想把它抽象一下先，建个Db类：
img12
Db类很简单基本没有什么可说的，唯有它的GetConnection方法值得一说，我们将上面的类图换个视角看一看：
img13
Db类的GetConnection方法构建数据库连接的任务是通过委托ADO.NET的DbProviderFactory类型的对象完成的，而dbProviderFactory作为DbProviderFactory类型的实例是通过ADO.NET的DbProviderFactories.GetFactory(this.ProviderName)静态方法传入ProviderName字符串构建的
img14
当然除了Db类外，我们也需要为表、表列、视图、视图列类别的元数据建模，不过它们四个并没有出彩的地方：
img15
还记得前文提到的数据库上的那四个视图接口么？上图的这四个对象模型多映射的就是数据库中的那四个视图（关系模型）。Db类型的对象不需要持久化吗？当然需要，它持久化到数据库中的Database表：
img16
同样Database表也没有什么出彩的地方，前文有一张图上提到数据库连接“引导库”，Database表所在的库就是这个引导库。
模型建好的，为了简化问题，就把上面的Db模型、DbTable模型、DbView模型、DbTableColumn模型和DbViewColumn模型当数据访问模型。现在基于这四个模型定义一套元数据访问接口：
img17
目前来说有意义的是图上红色矩形圈住的几个方法。这几个方法就是用以实现对Extended Properties类别的数据库元数据的增删改操作的，它们都是通过调用一个很臭的私有方法实现的：
img18
至此，终于我们实现了对数据库的Extended Properties类别的元数据的管理。元数据填好了就可以供我们所用了。现在让我们把元数据读成下图所示的形式。这张图完整的记录的数据库、表、表列、视图、视图列的元数据以及Extended Properties类别的元数据。
img19
好了，现在我们可以修改Entity Framwork的T4实体类代码生成模板了。
img20
首先构建数据库元数据提供程序，然后调用它的GetDbDoc方法传入数据库名查询出给定的数据库的文档。该文档是一张对象图，其对象间的关系参见上面贴过的图。
沿着Entity Framwork的T4模板代码往下找，下面是生成类的代码，我们在上面添加类注释：
img21
下面是生成普通属性的代码，我们在上面添加属性注释：
img22
好了，现在运行自定义过Entity Framwork的T4代码模板，看一下效果：
img23
如愿的生成了注释。
后话：
其实设计这个数据库元数据管理模板本来的目的不是生成实体代码注释，而是为了生成数据库文档。之所以要在查看文档时自动生成是因为众所周知的一个问题，文档很容易过期，没人维护。数据库文档模块做好后发现数据库文档上的信息对实体带来同样有意义，为Entity Framwork的实体代码生成注释只是数据库元数据管理模块的意外惊喜。生成的文档效果如下：
img24
img25
img26
（完）
本文链接：http://www.cnblogs.com/xuefly/p/3234445.html，转载请注明。
没有评论:
发表评论