Apa perbedaan antara inversedBy dan mappedBy?

Saya mengembangkan aplikasi saya menggunakan Zend Framework 2 dan Doctrine 2.

Saat menulis anotasi, saya tidak dapat memahami perbedaan antara mappedBydan inversedBy.

Kapan saya harus menggunakan mappedBy?

Kapan saya harus menggunakan inversedBy?

Kapan saya harus menggunakan keduanya?

Berikut ini contohnya:

 /**
 *
 * @ORM\OneToOne(targetEntity="\custMod\Entity\Person", mappedBy="customer")
 * @ORM\JoinColumn(name="personID", referencedColumnName="id")
 */
protected $person;

/**
 *
 * @ORM\OneToOne(targetEntity="\Auth\Entity\User")
 * @ORM\JoinColumn(name="userID", referencedColumnName="id")
 */
protected $user;

/**
 *
 * @ORM\ManyToOne (targetEntity="\custMod\Entity\Company", inversedBy="customer")
 * @ORM\JoinColumn (name="companyID", referencedColumnName="id")
 */
protected $company;

Saya melakukan pencarian cepat dan menemukan yang berikut, tetapi saya masih bingung:

• Contoh 1
• contoh 2
• contoh 3

• mappedBy harus ditentukan di sisi terbalik dari pengaitan (dua arah)
• inversedBy harus ditentukan di sisi yang memiliki asosiasi (dua arah)

dari dokumentasi doktrin:

• ManyToOne selalu memiliki sisi yang memiliki assocation dua arah.
• OneToMany selalu merupakan sisi kebalikan dari asumsi dua arah.
• Sisi yang memiliki asumsi OneToOne adalah entitas dengan tabel yang berisi kunci asing.

Lihat https://www.doctrine-project.org/projects/doctrine-orm/en/latest/reference/unitofwork-associations.html

Jawaban di atas tidak cukup bagi saya untuk memahami apa yang sedang terjadi, jadi setelah mendalami lebih dalam saya rasa saya memiliki cara untuk menjelaskannya yang akan masuk akal bagi orang-orang yang berjuang seperti saya untuk mengerti.

inversedBy dan mappedBy digunakan oleh mesin DOKTRIN INTERNAL untuk mengurangi jumlah kueri SQL yang harus dilakukan untuk mendapatkan informasi yang Anda butuhkan. Untuk lebih jelasnya jika Anda tidak menambahkan inversedBy atau mappedBy, kode Anda akan tetap berfungsi tetapi tidak akan dioptimalkan .

Jadi misalnya, lihat kelas-kelas di bawah ini:

class Task
{
    /**
     * @var int
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var string
     *
     * @ORM\Column(name="task", type="string", length=255)
     */
    private $task;

    /**
     * @var \DateTime
     *
     * @ORM\Column(name="dueDate", type="datetime")
     */
    private $dueDate;

    /**
     * @ORM\ManyToOne(targetEntity="Category", inversedBy="tasks", cascade={"persist"})
     * @ORM\JoinColumn(name="category_id", referencedColumnName="id")
     */
    protected $category;
}

class Category
{
    /**
     * @var int
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var string
     *
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;

    /**
     * @ORM\OneToMany(targetEntity="Task", mappedBy="category")
     */
    protected $tasks;
}

Kelas-kelas ini jika Anda menjalankan perintah untuk menghasilkan skema (misalnya, bin/console doctrine:schema:update --force --dump-sql) Anda akan melihat bahwa tabel Kategori tidak memiliki kolom di atasnya untuk tugas. (ini karena tidak ada anotasi kolom di atasnya)

Hal penting yang harus dipahami di sini adalah bahwa tugas variabel hanya ada di sana sehingga mesin doktrin internal dapat menggunakan referensi di atasnya yang bertuliskan Kategori mappedBy. Sekarang ... jangan bingung di sini seperti saya dulu ... Kategori TIDAK mengacu pada NAMA KELAS , ini mengacu pada properti di kelas Tugas yang disebut 'dilindungi $ kategori'.

Seperti bijaksana, pada kelas Tasks properti $ category menyebutkan itu inversedBy = "tugas", perhatikan ini jamak, ini BUKAN JAMAK NAMA KELAS , tetapi hanya karena properti disebut 'dilindungi $ tugas' dalam Kategori kelas.

Setelah Anda memahami ini, menjadi sangat mudah untuk memahami apa yang dilakukan inversedBy dan mappedBy dan bagaimana menggunakannya dalam situasi ini.

Sisi yang mereferensikan kunci asing seperti 'tugas' dalam contoh saya selalu mendapatkan atribut inversedBy karena perlu mengetahui kelas apa (melalui perintah targetEntity) dan variabel apa (inversedBy =) pada kelas itu untuk 'bekerja mundur' sehingga berbicara dan mendapatkan informasi kategori dari. Cara mudah untuk mengingat ini, adalah kelas yang memiliki foreignkey_id adalah kelas yang harus memiliki inversedBy.

Sedangkan dengan kategori, dan properti $ tugasnya (yang tidak ada di tabel ingat, hanya sebagian dari kelas untuk tujuan pengoptimalan) adalah 'tugas' MappedBy, ini menciptakan hubungan resmi antara dua entitas sehingga doktrin sekarang dapat dengan aman gunakan pernyataan JOIN SQL, bukan dua pernyataan SELECT yang terpisah. Tanpa mappedBy, mesin doktrin tidak akan tahu dari pernyataan JOIN itu akan membuat variabel apa di kelas 'Tugas' untuk meletakkan informasi kategori.

Semoga ini menjelaskannya sedikit lebih baik.

Dalam hubungan dua arah memiliki sisi memiliki dan sisi terbalik

mappedBy : dimasukkan ke Sisi kebalikan dari hubungan dua arah Untuk merujuk ke sisi pemiliknya

inversedBy : dimasukkan ke Sisi yang memiliki hubungan dua arah Untuk merujuk ke sisi kebalikannya

DAN

mappedBy digunakan dengan deklarasi pemetaan OneToOne, OneToMany, atau ManyToMany.

inversedBy atribut yang digunakan dengan deklarasi pemetaan OneToOne, ManyToOne, atau ManyToMany.

Perhatian : Sisi yang memiliki hubungan dua arah, sisi yang berisi kunci asing.

Ada dua referensi tentang inversedBy dan mappedBy ke Doctrine Documentation: First Link , Second Link

5.9.1. Sisi Memiliki dan Terbalik

Untuk pengaitan Banyak-Ke-Banyak, Anda dapat memilih entitas mana yang merupakan pemilik dan sisi kebalikannya. Ada aturan semantik yang sangat sederhana untuk memutuskan sisi mana yang lebih cocok untuk menjadi sisi pemilik dari perspektif pengembang. Anda hanya perlu bertanya pada diri sendiri, entitas mana yang bertanggung jawab atas manajemen koneksi dan memilihnya sebagai pihak yang memiliki.

Ambil contoh dua entitas Article dan Tag. Kapan pun Anda ingin menghubungkan Artikel ke Tag dan sebaliknya, sebagian besar Artikel yang bertanggung jawab atas hubungan ini. Setiap kali Anda menambahkan artikel baru, Anda ingin menghubungkannya dengan tag yang ada atau yang baru. Formulir create Article Anda mungkin akan mendukung gagasan ini dan memungkinkan untuk menentukan tag secara langsung. Inilah mengapa Anda harus memilih Artikel sebagai sisi kepemilikan, karena ini membuat kode lebih mudah dipahami:

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html