Comments on: Inheritance with symfony and Doctrine ORM http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/ A Blog About Software Development, Databases, And Stuff That Doesn't Have To Do With Computers Tue, 22 Jun 2010 12:48:22 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: David http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/comment-page-1/#comment-398 David Tue, 15 Jun 2010 19:21:42 +0000 http://jasonswett.net/blog/?p=263#comment-398 What I'd like to find is a method of having the objects so that the common values are in the parent table and only the sub-class specific columns are in a separate table (that is handled auto-magically, as that is what I am doing by hand currently). cow (purpose) -> farm_animal (name, sound, leg_count) milk_cow (quantity) -> cow (purpose) -> farm_animal What I’d like to find is a method of having the objects so that the common values are in the parent table and only the sub-class specific columns are in a separate table (that is handled auto-magically, as that is what I am doing by hand currently).

cow (purpose) -> farm_animal (name, sound, leg_count)
milk_cow (quantity) -> cow (purpose) -> farm_animal

]]> By: Prasad http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/comment-page-1/#comment-349 Prasad Thu, 10 Jun 2010 08:28:06 +0000 http://jasonswett.net/blog/?p=263#comment-349 Agree with Kev. Concrete Inheritance is used primarily for different entities of the same parent class example 1: types of 'people': user, agent, admin, supplier contact, customer contact, employee example 2: options (name, value): gender, phone-type, account types, dept codes Agree with Kev.
Concrete Inheritance is used primarily for different entities of the same parent class

example 1: types of ‘people’: user, agent, admin, supplier contact, customer contact, employee

example 2: options (name, value): gender, phone-type, account types, dept codes

]]> By: Kev http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/comment-page-1/#comment-263 Kev Mon, 31 May 2010 18:31:06 +0000 http://jasonswett.net/blog/?p=263#comment-263 The key advantage I found with using the column aggregation is that you can use dql to query the parent table and then get back the child objects. This will hopefully come in real handy on a project I'm working on where there's a public timeline of actions and when I query get the last 20 actions I only need to query one table and every entry in the timeline can have it's own individual ID The key advantage I found with using the column aggregation is that you can use dql to query the parent table and then get back the child objects. This will hopefully come in real handy on a project I’m working on where there’s a public timeline of actions and when I query get the last 20 actions I only need to query one table and every entry in the timeline can have it’s own individual ID

]]> By: Raphael http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/comment-page-1/#comment-236 Raphael Fri, 28 May 2010 21:55:45 +0000 http://jasonswett.net/blog/?p=263#comment-236 Good post! I agree with the conclusion that concrete inheritance mode is the best one among the three. But the mileage may vary depending on the specific need and circumstances. I wish to add the issue with concrete inheritance which nini has just raised. Even the concrete inheritance mode is not complete enough for the needs of true object-oriented logic: although there exists a top-level table farm_animal, this table will always be empty. The dogs, cows and chicken are exclusively stored in their respective tables, and none of them at all in the base class table. This arrangement is unlucky, as it inhibits browsing and quering through _all_ FarmAnimals, no matter which their (sub-)class is. So e.g. it is not possible to search for an animal called "Rosa", without knowing whether Rosa is a dog or a cow. And more importantly, as nini is stating, you can't setup an association between FarmAnimal and e.g. Farm ("a farm has zero, one or more animals"). Doctrine 2.0 may sometimes offer true full inheritance functionality by introducing "table inheritance". That mode should avoid any redundancy (no same field exists in multiple tables) and then have the base class' table store its part of each object, now allowing queries to be made on FarmAnimal level. Good post!

I agree with the conclusion that concrete inheritance mode is the best one among the three. But the mileage may vary depending on the specific need and circumstances.

I wish to add the issue with concrete inheritance which nini has just raised. Even the concrete inheritance mode is not complete enough for the needs of true object-oriented logic: although there exists a top-level table farm_animal, this table will always be empty. The dogs, cows and chicken are exclusively stored in their respective tables, and none of them at all in the base class table. This arrangement is unlucky, as it inhibits browsing and quering through _all_ FarmAnimals, no matter which their (sub-)class is.
So e.g. it is not possible to search for an animal called “Rosa”, without knowing whether Rosa is a dog or a cow.
And more importantly, as nini is stating, you can’t setup an association between FarmAnimal and e.g. Farm (“a farm has zero, one or more animals”).

Doctrine 2.0 may sometimes offer true full inheritance functionality by introducing “table inheritance”. That mode should avoid any redundancy (no same field exists in multiple tables) and then have the base class’ table store its part of each object, now allowing queries to be made on FarmAnimal level.

]]> By: jason http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/comment-page-1/#comment-184 jason Tue, 18 May 2010 13:40:43 +0000 http://jasonswett.net/blog/?p=263#comment-184 Nini, if there's a one-to-one relationship between User and Admin, what's wrong with having Document's foreign key point to User? Nini, if there’s a one-to-one relationship between User and Admin, what’s wrong with having Document’s foreign key point to User?

]]> By: nini http://jasonswett.net/inheritance-with-symfony-and-doctrine-orm/comment-page-1/#comment-182 nini Tue, 18 May 2010 09:32:44 +0000 http://jasonswett.net/blog/?p=263#comment-182 Concrete inheritance doesn't work well with relations between models because of strict foreign keys checks (Mysql/Innodb). So if you have such schema: --- detect_relations: true User: columns: username: string Admin: inheritance: extends: User type: concrete Moderator: inheritance: extends: User type: concrete Document columns: description: string user_id: integer then it will be not possible to save a Document, say, for an Administrator, because mysql will try to check if such user exists in User(!) table, not in administrator table. So it why i'm forced to use column aggregation inheritance. Concrete inheritance doesn’t work well with relations between models because of strict foreign keys checks (Mysql/Innodb). So if you have such schema:

—
detect_relations: true
User:
columns:
username: string

Admin:
inheritance:
extends: User
type: concrete

Moderator:
inheritance:
extends: User
type: concrete

Document
columns:
description: string
user_id: integer

then it will be not possible to save a Document, say, for an Administrator, because mysql will try to check if such user exists in User(!) table, not in administrator table. So it why i’m forced to use column aggregation inheritance.

]]>