Doctrine YAML Data Fixture Question

Question

where can i learn more abt creating database markup in yaml and data fixtures.

i followed a tutorial and they create a relationship like so: under relations in both User and Car. my qn is why is 'type: many' in Car. can i have it in User instead (just curious)?

abt data types. different database have different database support. i thought that in MySQL (InnoDB as used here) integer shld be tinyint(x), bigint(x), int(x) ... or string shld be varchar not string? isit not strict what i shld use here?

options:
  type: INNODB
  collate: utf8_general_ci
  charset: utf8

User:
  columns:
    id:
      type: integer
      primary: true
      autoincrement: true
    name: string(300)
    email: string(300)
    phone: string(9)
    car_id: integer
  relations: 
    Car: 
      local: car_id
      foreign: id
Car:
  columns:
    id:
      type: integer
      primary: true
      autoincrement: true
    brand: string(300)
  relations:
    Users:
      class: User
      foreign: car_id
      local: id
      type: many

UPDATE 1

1. "it is only necessary to specify the relationship on the end where the foreign key exists" in my example, that will be? do they mean the FK table (car) or the FK column (user)?

2. i dont see TEXT data type, is that clob (Character Large OBject)? – iceangel89 0 secs ago [delete this comment]

3. what is foreignAlias? is there a alias too?

UPDATE 2

this will be abit long, i just wish to clarify some of the code examples in the Doctrine YAML Schema Files docs page. focus on the relationships section -> in // comments

User:
  columns:
    username:
      type: string(255)
    password:
      type: string(255)
    contact_id:
      type: integer
  relations:
    Contact:
      class: Contact // if the table is named Contact, class will be Contact also?
      local: contact_id 
      foreign: id
      foreignAlias: User // whats alias for? 
      foreignType: one // one contact ... to ...
      type: one // one user?

Contact:
  columns:
    first_name:
      type: string(255)
    last_name:
      type: string(255)
    phone:
      type: string(255)
    email:
      type: string(255)
    address:
      type: string(255)
  relations:
    User:
      class: User
      local: id
      foreign: contact_id
      foreignAlias: Contact
      foreignType: one
      type: one

regarding the many to many example, what does the following mean?

attributes:
  export: all
  validate: true

tableName: group_table

refClass: GroupUser

Answer 1

where can i learn more abt creating database markup in yaml and data fixtures.

Doctrine manual, “YAML schema files” and “Data Fixtures” chapters.

can i have it in User instead (just curious)?

Yes, but this section will be called foreignType then. Here, an example:

User:
  columns:
    id:
      type: integer
      primary: true
      autoincrement: true
    name: string(300)
    email: string(300)
    phone: string(9)
    car_id: integer
  relations: 
    Car: 
      local: car_id
      foreign: id
      foreignType: many

abt data types...

Well, Doctrine column types and database column types are “slightly” different. Just compare list of Doctrine column types and, say, MySQL's one.

Answer 2

I know this is old, but these are things I've found confusing, and still do. In fact I'm not expert in all the possibilities, this is just based on what works for me. I think you may be looking for many-to-many relations, but I completely avoid the Doctrine support for them, and instead define my own association tables explicitly, so I only ever use one-to-many and one-to-one relations.

As noted in UPDATE1, you only specify the relationship on the end that has the foreign key.

1. In this case, User has a column car_id that is a foreign key that refers to the id column of Car. So on the User end, the relation is with Car, the local column containing the key value is car_id, and the column in the other (foreign) table to which it refers is id.
2. Doctrine defines its own data types, and automatically maps them onto the data types of the particular database you are using. develop7 gave links to the documentation, or you can look in the doctrine sources.
3. foreignAlias gives a name to the relation on the foreign side. There is no alias because the name of the relation on the side containing the foreign key is given by the name used at the level below relations:, which is commonly specified as the name of the table to which the foreign key refers.

Regarding UPDATE 2:

class: Contact The yaml for User says that it has a relation named Contact which refers to the class Contact. By default, class names and table names are the same; the yaml schema deals only with class names, though it is possible to tell it to use a different table name for a given class.

foreignAlias: User The name of the relation from Contact to User is "User". As explained above, there is nothing called "alias", the name of the relation from User to Contact is "Contact", because that's the name in the list of relations for User under which this line appears. Of course these default relation namings fall apart if you happen to have more than one relationship between the same two classes; you need the ability to give explicit relation names that differ from the class names. The names of relations are important because you use them in DQL joins.

foreignType: one A Contact (the foreign side) has one User

type: one A User (the local side) has one Contact.

Note that this example is a little unusual in showing explicitly both sides of the same relation. Normally, you'd show it only on the side containing the foreign key (the User side). Since a User contains a foreign key pointing to a Contact, the "type" can only be "one". But the foreignType could be "many", indicating that a given Contact could be pointed-to by many Users, though in this case it is specified that only one User can refer to a given Contact.

I don't actually know what would happen if you specified the type as "many". Implementing that would require an extra association table like many-to-many relations do, and I don't happen to know if Doctrine would create such a table "automatically" as it does for many-to-many relations. For my use of Doctrine, I avoid implicit machinery based on naming conventions that I don't understand as much as possible, so I turn off "detect_relations" and avoid many-to-many relations.