2013-10-27 10 views
26

"ext_translations"テーブルにすべての翻訳を含むテーブルがあります。翻訳可能なフィールドを持つSonataAdminBundle

翻訳が素晴らしいです。問題は今のところです:sonata-adminバンドルでこれらの翻訳を管理したいのです。

私はすでにドキュメントを見つけました。どのようにソナタ管理で仕事の拡張を取得するのですか?しかし、私のケースでは、のテーブル/エンティティ(複数のエンティティ用)があります。

したがって、このドキュメントによれば、http://www.elao.com/blog/symfony-2/doctrine-2/how-to-manage-translations-for-your-object-using-sonataadminbundle.html私のmappedBy属性は何ですか(下記参照)。

ext_translationsテーブル:

mysql> show columns from ext_translations; 
+--------------+--------------+------+-----+---------+----------------+ 
| Field  | Type   | Null | Key | Default | Extra   | 
+--------------+--------------+------+-----+---------+----------------+ 
| id   | int(11)  | NO | PRI | NULL | auto_increment | 
| locale  | varchar(8) | NO | MUL | NULL |    | 
| object_class | varchar(255) | NO |  | NULL |    | 
| field  | varchar(32) | NO |  | NULL |    | 
| foreign_key | varchar(64) | NO |  | NULL |    | 
| content  | longtext  | YES |  | NULL |    | 
+--------------+--------------+------+-----+---------+----------------+ 

MappedBy:「私は(オブジェクトクラス(エンティティ)+名前(属性の複合キーを持っている:私の知る限りは、ここでの問題を理解して

/** 
    * @ORM\OneToMany(targetEntity="ProfileTranslation", mappedBy="object", cascade={"persist", "remove"}) 
    */ 
    protected $translations; 

)+ foreignKey(エンティティのid))、それでは 'mappedBy'はこれをどのように参照するのですか?

翻訳可能なエンティティごとに追加のクラスを作成したくありません(上のチュートリアルのように)

+0

私はSonataAdminBundleに精通していませんが、一般的にDoctrineでは「ユースケース1」の何が問題になっていますか?http://docs.doctrine-project.org/en/latest/tutorials/composite-primary-keys .html この場合、Doctrineは関係を処理し、オブジェクトの正しい翻訳を返しますか? – Feras

答えて

1

あなたの状況は非常に複雑です。おそらく最良のことは、あなたがどんなアノテーションを使ってもいけない場合です。override the repository class、あなた自身のロジックをすべて構築してください。

フェラスがコメントしたように、Doctrine 2.1が複合キーを主キーとして作成して以来、この新しい能力を活用しようとすることができます。

Doctrine 2は複合主キーをネイティブにサポートしています。コンポジットキー は非常に強力なリレーショナルデータベースのコンセプトであり、Doctrine 2がコンポジットプライマリキー ユースケースの多くをサポートするように、 を十分に配慮しました。 Doctrine 2.0の場合、基本データ型の複合キーは であり、Doctrine 2.1では主キーとしての外部キーでさえも がサポートされています。

ドキュメントで

、我々はあなたに、多かれ少なかれ似ているユースケースに良い例があります:エンティティ(例えば条)の

動的属性。各記事 には、主キー「article_id」と 「attribute_name」を持つ多くの属性があります。

あなたがここでの例を見ることができます:

しかし、そのアプローチは、1つのエンティティのみを考慮するので、私たちはあなたのニーズに適合するように持っているhttp://docs.doctrine-project.org/en/latest/tutorials/composite-primary-keys.html#use-case-1-dynamic-attributes。私たちは、この手順を実行することができます:

  1. あなたext_translationsテーブル

    CREATE VIEW profile_ext_translations 
    AS 
    SELECT * 
    FROM ext_translations 
    WHERE object_class = 'Profile' 
    
  2. の見解のようなものを作成し、別のエンティティを作成し、そのビューのための、すなわちので、今

    ** 
    * @Entity 
    */ 
    class ProfileExtTranslations 
    { 
    
        /** 
        * @ORM\ManyToOne(targetEntity="Profile", inversedBy="translations") 
        * @ORM\JoinColumn(name="foreign_key", referencedColumnName="id", onDelete="CASCADE")*/ 
        private $profile; 
    
    /** @Id @Column(type="string") */ 
    private $field; 
    
    //Other fields and methods 
    
    
    } 
    
  3. そして、プロファイル・エンティティのコードを翻訳のmappedByで、あなただけの使用、:次のように、複合主キーを持つエンティティProfileExtTranslationsを持っているでしょう

    /** 
    * @ORM\OneToMany(targetEntity="ProfileExtTranslation", mappedBy="profile", cascade={"persist", "remove"}) 
    */ 
    protected $translations; 
    

これはおそらくリトルチューニングでは、動作させる必要があります。

+0

ステップバイステップで良いステップのように見えます。私はステップ1と2を行いましたが、GedmoTranslatable(https://github.com/l3pp4rd/DoctrineExtensions/blob/master/doc/translatable.md)を使用しているので、ステップ3で少し混乱しています。私は$ translationsのようなプロパティを持っていません。私は翻訳したいプロパティのようなものを持っています(例えばname)。そしてそれは@Gedmo \ Translatableで注釈が付けられます。私のext_translationsでは、 'field'というフィールドがこれを識別します。だから、私はext_translationsのような行を持っています:object_class = 'Profile'、field = 'name'。 – eav

+0

ええ、私はそれを取得しますが、私は翻訳を使用して以来、あなたの質問で言及されているものであり、またその例では、プロファイルクラスで何があります。リンクしたチュートリアルに従っている場合は、GedmoまたはDoctrineによって何らかの形で埋められている翻訳プロパティが必要です。私はGedmoの仕組みを知りませんが、このようなシナリオは例のシナリオと同等でなければならないので、それを理解することができます –

+0

もう一度今日見てみましょう - あなたは賞金を得るでしょう;-) – eav

関連する問題