DDC-551: Consider adding ability to specify additional join conditions on a @JoinTable / @JoinColumn #5059

Closed
doctrinebot opened this Issue Apr 28, 2010 · 18 comments

4 participants

@doctrinebot

Jira issue originally created by user mjh_ca:

Per discussion with beberlei and romanb in #doctrine-dev yesterday, opening this ticket as a "feature request" to support migrating legacy schemas with a special many-to-many mapping to Doctrine.

Consider the following schema:

CREATE TABLE categories (
    category*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT,
    content_type ENUM('posts', 'videos'),
    /** ... **/
    PRIMARY KEY (category_id)
) ENGINE=InnoDB;

CREATE TABLE content*category*association (
    content_id BIGINT UNSIGNED NOT NULL,
    category_id BIGINT UNSIGNED NOT NULL,
    content_type ENUM('posts', 'videos'),
    PRIMARY KEY (content*id, category_id, content*type),
    FOREIGN KEY (category*id, content_type) REFERENCES categories(category_id, content*type) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;

CREATE TABLE posts (
    post*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT,
    /** ... **/
    PRIMARY KEY (post_id)
) ENGINE=InnoDB;

CREATE TABLE videos (
    video*id BIGINT UNSIGNED NOT NULL AUTO*INCREMENT,
    /** ... **/
) ENGINE=InnoDB;

There is a Many-To-Many relationship between each of the posts and videos table (via the contentcategory_association table) to the categories table. The difference from a standard many-to-many relationship is there is an extra column in the association table (content_type) which must be included in the join condition to return correct results. Since both the videos and posts table have their own autonumber primary keys, a join against the association table must include an extra condition (i.e. INNER JOIN ... ON ... AND content_category_association.contenttype = 'posts').

Perhaps you could allow passing of additional properties to @JoinTable / joinColumns to specify the additional join condition .. i.e.:

/*** @Entity **/
class Video
{
  /****
   * @ManyToMany(targetEntity="Category")
   * @JoinTable(name="content*category*association",
   *      joinColumns={@JoinColumn(name="content*id", referencedColumnName="video*id")},
   *      inverseJoinColumns={@JoinColumn(name="category*id", referencedColumnName="video*id")},
   *      extraJoinTerms={@JoinTerm(content_type="video")}
   *      )
   */
  private $categories;

  // ...
}

/*** @Entity **/
class Category
{
    // ...
}

Certainly this schema is not ideal from a pure OO perspective. Class inheritance with a discriminator column may have been a better way to do this, thereby allowing a globally unique "content_id" for all types of content, negating the need for the extra column in the association table. However, it would nonetheless be helpful to have this additional capability within Doctrine to avoid having to re-factor such a legacy schema.

@doctrinebot

Comment created by yaroslav:

Would be great to get this functionality

@doctrinebot

Comment created by @beberlei:

Assigned to asm89

@doctrinebot

Comment created by @beberlei:

Scheduled for 2.2

@doctrinebot

Comment created by @asm89:

I've been working on this ticket over here:
https://github.com/asm89/doctrine2/tree/[DDC-551](http://www.doctrine-project.org/jira/browse/DDC-551)

Latest thing I added was the state of the collection of filters, because this is needed for parsing (and sometimes not parsing) the queries to generate SQL. I'd like some feedback about the state keeping. More information at the commit:
asm89@2653d73

At this point the EntityManager keeps track of this state, but maybe it would be nice to have a separate FilterCollection keep track of the state/hashes etc?

@doctrinebot

Comment created by @beberlei:

This issue is referenced in Github Pull-Request GH-224
#224

@doctrinebot

Comment created by @beberlei:

Related Pull Request was closed: #210

@doctrinebot

Comment created by @beberlei:

Related Pull Request was closed: #224

@doctrinebot

Comment created by @beberlei:

Implemented

@doctrinebot

Issue was closed with resolution "Fixed"

@doctrinebot

Comment created by @beberlei:

This issue is referenced in Github Pull-Request GH-225
#225

@doctrinebot

Comment created by @beberlei:

Related Pull Request was closed: #225

@doctrinebot

Comment created by @beberlei:

This issue is referenced in Github Pull-Request GH-227
#227

@doctrinebot

Comment created by @beberlei:

Related Pull Request was closed: #227

@doctrinebot

Comment created by darkangel:

Alex mentioned on IRC that filters do not provide the functionality that the OP requires, so this issue should really re-opened, unless I'm missing something?

@doctrinebot

Comment created by @beberlei:

This issue is referenced in Github Pull-Request GH-237
#237

@asm89 asm89 was assigned by doctrinebot Dec 6, 2015
@doctrinebot doctrinebot added this to the 2.2 milestone Dec 6, 2015
@doctrinebot doctrinebot closed this Dec 6, 2015
@superdav42

@asm89 I don't see how this resolves the original issue. It requires adding conditions on the related join and filters don't seem to have access to that kind of information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment