忍者ブログ
  ちゃんとカテゴリ分けされておりませんので、 記事をお探しならブログ内検索が便利です。 ご活用くださいませー+.(≧∀≦)゚+.゚
Admin*Write*Comment
[1]  [2]  [3]  [4]  [5]  [6]  [7]  [8]  [9

先日ちゃんとテストもしないで公開したら、バグがひどかったので修正します。
先日のは非公開にしまーす。

PostgreSQLのpg_dumpを
pg_dump db_name > db_name.dmp
見たく取得したはいいものの、実際にリストアするときに特定のテーブルだけ、リストアしたいねー
なんてことはよくあります。
と、いうことで、あまり大きいファイルには向かないけど、ファイルを分割するスクリプトをPythonで書いてみました。

python
import os
dump_file_path = './db_name.dmp'
dump_path = os.path.dirname(dump_file_path)
dump_file = os.path.basename(dump_file_path)

## define
# 処理を止める行数(0で最後まで)
break_point = 0
line_no = 0
file_no = 0
delimiter_flg = 0
prefix = u's'
init_file = True
log_file = '%s_log_%s' % (prefix, dump_file)

# main

# initialyze outputo file
if init_file:
  old = filter(lambda x: x.startswith(prefix), os.listdir(dump_path))
  for _file in old: os.unlink(os.path.join(dump_path, _file))

# splitting
f = open(dump_file_path, 'rb')
for line in f:
  line_no += 1
  if line.strip() == '--':
    if delimiter_flg == 2:
      delimiter_flg = 1
      file_no += 1
      print '次のセクションに移動しました。 処理行数[%s], 処理セクション[%s]' % (line_no, file_no)
    else:
      delimiter_flg += 1
  elif line.startswith('--'):
    open(log_file, 'ab').write('\t'.join([str(line_no), str(file_no), line]))
  open('%s%03d_%s' % (prefix, file_no, dump_file), 'ab').write(line)
  # print (file_no, delimiter_flg, line.strip())
  if 0 < break_point < line_no:
    break

f.close()

これでカレントディレクトリに分割されたファイルが出来上がるので
中身を確認しつつ、目的のテーブルのデータをダンプしてください。
INDEXとかは面倒だと思います。
そんな書き方はナンセンス!
なんてFBは随時受け付けますが、理解できないかもです(-_-;)

確認環境
Python2.7.3
PostgreSQL 9.3.3

拍手

PR



Linux上で作業していた時に表計算ソフトからDBにつなげたらいいなーって思ったら案外簡単にできるようでした。

http://superuser.com/questions/391242/how-do-i-connect-to-a-postgresql-server-using-libreoffice-base

今回はPostgreSQLの場合です。

Version
Calc:4.2.0.4 (en version)
Postgres: 9.2.4(source compile)

拍手




いつも使用しているテンプレートのCSSが更新されたみたいです。
ちゃんと、横幅が調整されるようになったみたいで、うれしいですね^^

拍手




完全によそ様の引用です ( ̄▽ ̄;)
Python2.7.3で確認済み

colors = {
    'clear': '\033[0m',
    'black': '\033[30m',
    'red': '\033[31m',
    'green': '\033[32m',
    'yellow': '\033[33m',
    'blue': '\033[34m',
    'purple': '\033[35m',
    'cyan': '\033[36m',
    'white': '\033[37m'
}
for k, v in colors.iteritems():
    print '%s%s' % (v, k)

参考元:
http://d.hatena.ne.jp/heavenshell/20090909/1252509749

拍手




MySQLの場合、MASTER側でエラーが起きるようなSQLを発行してもSLAVE側にそのSQLが流れてしまう場合があり、SLAVEで実行した際に同じようにエラーになり、止まってしまうことがあるようです。
原因は多々あると思いますが、現在止まっているSQLを無視して問題ないと判断できる場合はそのSQLの実行をスキップして次に進めることができるみたいです。
その対処方法の備忘録です。

-- 現在のSLAVEの稼働状況を確認
SHOW SLAVE STATUS \G
-- 厳密には停止の必要はないけれどここではSLAVEの機能そのものをいったん再起動します
STOP SLAVE;
-- 現在出ているエラーをスキップします
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
-- SLAVE(レプリケーション)を再開します
START SLAVE ;
-- 少し待ちます
SELECT SLEEP(2);
-- 再度SLAVEの稼働状況を確認します
SHOW SLAVE STATUS \G

拍手




postgresql は普段あまり使わないDBなのでついついスキーマ変更用のSQLを忘れてしまいますね。゚・(>Д<)・゚。

ということで備忘録。
postgresql 9.2 の場合です。
8とか7はおそらく違います。


ALTER TABLE table_name ALTER COLUMN column_name
  SET
    DATA TYPE data_type;


table_name:  対象のテーブル名
column_name: スキーマ変更対象のカラム名
data_type: 新しいスキーマ
 ex.)
 varchar(255)
 bigint


http://www.postgresql.jp/document/9.2/html/sql-altertable.html


14.10.27 追記
スキーマ長を増やすだけ(型は変えずに長さだけ変える場合)とは違い、型そのものを変更する場合は失敗する場合が多々あります。
例えば元のカラムがvarchar(10)で、integer(10)に変更を試みようとした場合でも、カラムの中には一見数字しか見えなくても型変換に失敗し、変更できないことがあります。
その場合はUSINGを使用して、元のデータと後のデータを指定してあげることで解決が可能です。
例を記載します。

ALTER TABLE table_name ALTER COLUMN available 
SET
  DATA TYPE BOOLEAN
    USING CASE
      WHEN available = 1
      THEN TRUE
      WHEN available = 2
      THEN FALSE
      END;



それでも失敗する場合は、INDEXをいったん削除しましょう。

拍手




現場でFacebookのデータをAPIで引っ張れないか?
という要件をいただきました。
わたし、、、Facebookに興味ないんですけど。。。

まぁ、そこはかとなく、仕事とプライベートってところでいざ調査開始 。+.。ヽ(*>∀<*)ノ。.+。キャハッ

簡単にわかったこととしては
https://graph.facebook.com
にアクセスするだけでJson形式のデータが返されるってことかな?

https://graph.facebook.com/[ユーザ名]
でそのユーザの何かが取れます (*´-ω・)ン?

ここまで書いて面倒になっちゃったので参考になるURLを記載しちゃいます(。-人-。)

http://facebook-docs.oklahome.net/archives/51906043.html
https://developers.facebook.com/blog/post/498/

ではでは (`-ェ´-、)ノ

拍手




しばらくninja Blogにログインできなかったのだけど、今日できましたemoji
なので、引き続きがんばりますねemoji
月一くらいになっちゃうのだけど…emoji

拍手




ApacheのRewriteLogについて、デベロッパーの皆さんの情報を集めていたのですが、どうにもうまくいかない。
と、いうことでちゃんとした本家のドキュメントを見てみました。

http://httpd.apache.org/docs/

どうやら2.0系&2.2系と2.4系では記述の仕方が変わっていたようです。

2.0
2.2
2.4

Apacheは英語サイトでも比較的わかりやすいですし、やはり本家が一番ですね・・・

---- Sample ----

☆2.2系
# Log to a file:
RewriteLog "/usr/local/var/apache/logs/rewrite.log"

# Log to a pipe:
RewriteLog "|/path/to/parser.pl"

# output level
RewriteLogLevel 3

☆2.4系
LogLevel alert rewrite:trace3



====補足====
2.0系2.2系ではLogの出力レベルを0~9の10段階で指定が可能。
0ではまったく出力されず、9ではかなり冗長的なLogになります。
でもぶっちゃけ3以上はかなり冗長です。

2.4系では行末付近のtrace3の3を変更することで出力を制御できます。
minは未確認ですが、maxは8です。
そして出力先は選べないようで[error_log]に集約されるようです。
もちろんVirtualHostなどをきっていればそちらのLogに吐かれます。

共通していえるのは.htaccessで制御できず、Apacheの再起動が必要になるため、レンタルサーバではきつそうだということです。

----End----

拍手




よく使うサイト集
ようは備忘録的に、、、

HTTPリクエストチェック
診断くん
env

URLエンコード・デコード
UrlEncode.net

正規表現
PHP正規表現チェッカー ver1.0.3

拍手



ブログ内検索
カレンダー
06 2017/07 08
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
カウンター
最新コメント
最新トラックバック
プロフィール
+ハンドル+
y_ayamori(purple)
+職業+
IT系エンジニア
+すまい+
さいたま
バーコード
ブログパーツ
アバター
Copyright © アナログを愛するデジタル生活館 All Rights Reserved.
photo by Kun material by Atelier Black/White Template by Kaie
忍者ブログ [PR]