フリースペース

Twitterでシェア FaceBookでシェア はてなブックマークでシェア

ブログ全般 - フリースペース
2018年11月22日21:14に更新(約21日前)
2018年10月4日13:05に作成(約70日前)

フリースペースです。

旧ブログの記事で質問があったり、特定の記事に紐づかないコメントはこちらのコメント欄に書き込んでください。

Twitterでシェア FaceBookでシェア はてなブックマークでシェア

記事にコメントする

名無し
2018年10月4日13:35にコメント(約70日前)

いつもブログ拝読しています。 フィードを登録しようとするとエラーになってしまいます。nginxの設定でhttpからhttpsへのリダイレクトがなされていないように見えます。お手数ですがご対応お願いいたします。

コメントに返信する

なりと
2018年10月4日18:28に返信(約70日前)

ご連絡ありがとうございます。

リダイレクト設定をしました。

名無し
2018年10月4日22:22にコメント(約70日前)

いつも拝見しております。 新しいブログの記事も楽しみにしています!

と言いつつ…旧ブログの記事で質問です。ManyToManyを使った自分自身へのリレーションで、記事ではform.pyの中でexcludeで自分自身を除外していたと思いますが、DetailViewやtemplateの中で自分自身を除外する場合はどのようにするとよいでしょうか。

コメントに返信する

なりと
2018年10月5日6:45に返信(約69日前)

詳細画面を開いた際に、ManyToMany(self)で紐づいたデータを表示したいが、その自分自身は除きたいということでしょうか。

その場合は、モデルのメソッドとして定義してしまうのが簡単だと思います。

class Post(models.Model):
    """ブログのポスト"""

    title = models.CharField("タイトル", max_length=255)
    text = models.TextField("中身")
    friend_posts = models.ManyToManyField("self", verbose_name="関連記事", blank=True)

    def __str__(self):
        return self.title

    def get_friends(self):
        return Post.objects.exclude(pk=self.pk)

テンプレートでは、{% for f_post in post.get_friends %} のように呼び出せます。

名無し
2018年10月5日9:21に返信(約69日前)

ありがとうございます! ご回答いただいた通りの内容の質問でした。とても参考になりました。

Markdown記法でコメント入れられるのも便利だなーと思いました。

ありがとうございました。

なりと
2018年10月9日13:06に返信(約65日前)

上のコードだとすべての記事(自分以外)が表示されます。

ManyToMany(self)で紐づいたもので、自分自身を除く場合(なので、自分自身も既に紐づいている場合)は以下のようにできます。

    def get_friends(self):
        return self.friend_posts.exclude(pk=self.pk)
名無し
2018年10月21日14:55に返信(約53日前)

ありがとうございます。

選択していないすべての記事が表示されてしまっていたのでとても助かりました。ありがとうございました。

生徒
2018年10月5日23:50にコメント(約69日前)

お世話になっております。 新ブログ完成おめでとうございます! 楽しみにしていました。

誠に恐れりいます、早速ですが質問させて下さい。

現在、私はnaritoさんのumedyの講義を拝見しながら、 さくらのVPS(centOS+nginx)にdjango製の自分のwebサービスをデプロイすることが出来ました(ありがとうございます!)。

これから行いたい事として、 このサーバー内に既存のwordpressサイトをdjangoと共存させる形で移管したいです。 しかし、このwordpressの適切な移管場所が分かりません。

wordpressの移管についてweb上の記事で調べると、

「wordpress本体はドキュメントルート(/usr/share/nginx/html)にアップロードする」

という内容が散見されるのですが、現在、djangoはhomeディレクトリにアップロードされています。

djangoはhomeディレクトリにアップロードされているのに、wordpressだけ上記のドキュメントルートにアップロードするというのはおかしいのではないかと考えています。

上記を踏まえて質問致します。

  1. 私のケースのように、djangoとwordpressを一つのVPSの中に入れることは可能でしょうか。
  2. 上記1が可能である場合、wordpressを格納するフォルダはどこが良いのでしょうか。homeの中にwordpressファイルを入れることは可能でしょうか。

コメントに返信する

なりと
2018年10月6日2:46に返信(約68日前)
  1. 可能です。

  2. ドキュメントルートで問題ございません。
    ドキュメントルートにhtmlファイルを置くだけで大抵のウェブサーバーではhttp://ドメイン/〇〇.html としてアクセスできますが、phpも似たようなことが簡単にできます(にわかPHP知識なので語弊があるかも)。なので、他の場所にwordpress関連ファイルをおこうとするとドキュメントルートの変更等が必要になります。

しかし、Pythonの場合はまたちょっと話は別です。公式サイトから抜粋します。

コードはどこに置くの?

(モダンなフレームワークを使わない) 古いプレーンな PHP の経験があるなら、これまでは Web サーバのドキュメントルート下 (/var/www といった場所) にコードを配置してきたことでしょう。 Django ではそうしないでください。 Python コードを Web サーバーのドキュメントルート下に置かないでください。コードをドキュメントルート下に置くと、 誰かがコードを Web を介して読めるようになってしまうからです。これは安全上良くありません。

コードはドキュメントルートの外、例えば /home/mycode の ような場所に置きましょう。

ですので、今回の例ならばwordpress関連はドキュメントルート(/usr/share/nginx/html)に、Django関連は/home にというのはおかしくなく、自然な対応です。

生徒
2018年10月6日10:05に返信(約68日前)

なるほど、完璧に理解できました。 誠に有難うございます!

名無し
2018年10月8日13:05にコメント(約66日前)

いつも拝見しております。恐れ入りますが、一つ質問がございます。

djangoで管理台帳を作成しています。 クラスAとクラスBがあり、クラスBにはForeignKeyでクラスAを保持しております。クラスAには台帳のメタデータ的な情報(例えば'開始日'と'回数'など。)を持たせて置き、その情報をもとにしてpandasのDataFrameで計算を回し、その計算の結果、複数のクラスBインスタンスが作成される、というイメージを持っております。

その場合、計算を回す関数はクラスAのmodels.pyに持たせておくのが自然でしょうか。

また、クラスAのインスタンスがデータベースにsaveされた瞬間に、計算の関数が呼び出され、自動的にクラスBのインスタンスが作成されてデータベースに保存されるようにすることは可能でしょうか。(クラスAのデータが削除された場合、クラスAの情報で作成されたクラスBのデータも削除される必要がある。)

この場合、クラスAの修正や削除がそれなりの回数発生するとした場合、データベースへのアクセス回数など、プログラムに負担がかかってしまうものなのかと、いろいろ気になりましたが、一般的な考え方はありますでしょうか。

宜しくお願いいたします。。

コメントに返信する

Uichi
2018年10月9日0:07に返信(約66日前)

旧ブログDjangoで、汎用ビュー(ListView, DetailView)の 以下の部分ですが、

class IndexViepw(generic.ListView):
    queryset = Post.objects.all()

IndexViepw ではなく IndexViewではないでしょうか。

細かくてすいませんが、よろしくおねがいします。

なりと
2018年10月10日14:22に返信(約64日前)

その場合、計算を回す関数はクラスAのmodels.pyに持たせておくのが自然でしょうか。

ビューは見通しをよくするのが良いとよく言われます。ただ、個人的にはビューで一度書いてみて、見通しが悪くなったり、他のビューでも同じコードが必要になりそうならモデル(又はフォーム)に定義する、といった感じで良いと思います。

また、クラスAのインスタンスがデータベースにsaveされた瞬間に、計算の関数が呼び出され、

このケースならシグナルを使うのがスムーズだと思います。

from django.db.models.signals import post_save
from django.dispatch import receiver
...
...
@receiver(post_save, sender=ModelA)
def create_model_b(sender, instance, created, **kwargs):
    # 更新ではなく新規作成された場合にこのフラグが使えます。
    if created:
        # 計算とモデルBの作成処理
        # instance引数に、モデルAインスタンスが入っています。

post_saveはsaveメソッドの後に呼ばれます。pre_saveや、削除処理の前後で使えるpre_delete, post_deleteもあります。 ドキュメント

この場合、クラスAの修正や削除がそれなりの回数発生するとした場合、データベースへのアクセス回数など、プログラムに負担がかかってしまうものなのかと、いろいろ気になりましたが

数件、数十件程度ならそこまで気にしなくてもよいと思いますが、気になる場合はbulk_create()のような一括作成に特化したものもあるので、そちらの利用を検討してください。

なりと
2018年10月10日14:23に返信(約64日前)

Uichi さん
IndexView が正しいです。わざわざのご連絡ありがとうございます。

名無し
2018年10月11日10:36に返信(約63日前)

ありがとうございます。

ビューとモデルの考え方、シグナル、データベースのご回答内容大変参考になりました。

早速シグナルで試してみたところ、うまくいきました。ビューがかなり見通し悪くなってきたので、モデルに移そうかと考え始めました。

いつもいつも、非常に助かっております。ありがとうございました。

ninjaのドメイン、いいですね(^^)