Setting Column name doesn't work predictably in associations

Foreign keys (or discriminator columns) are not intended to be mapped to properties. What do you need $shippingId for?

I see your point though there might be some use cases for wanting to access $shippingId (maybe storing in some kind of log that doesn't need the full set of shipping info) and not incur the expense of getting the shipping object.

@akeem: This is possible without mapping the shipping-id, although its not recommended for the reason that you are depending on internal Doctrien 2 APIs. This should only be done as a very last resort (performance reasons).

You can retrieve the identifier of the shipping proxy object by calling:

$shippingId = $em->getUnitOfWork()->getEntityIdentifier($entity->shipping);

As another solution you could, if required for a specific use-case, retrieve only the shipping ids and initialize shipping as partial objects:

SELECT o, PARTIAL s.{id} FROM Order o JOIN o.shipping s

Let my try to clarify, because I saw you tweeting that you dislike this "limitation".

A foreign key has no meaning in an object model. Foreign keys are how relational databases establish associations/relations between rows. In object-oriented programming objects establish associations through object references. In a sense, when you map a foreign key to an object property you leak detail of your relational schema into your object model. Detail that is only ever relevant to a relational database. If you would ever persist this object in another type of persistent storage, the foreign key has no meaning. This level of abstraction that D2 provides is rare among PHP ORMs. Most require you to have foreign keys as properties which is a major flaw of the abstraction.

It should be possible to map foreign keys to properties but this has very low priority because even if you want to do it, it can only be a workaround and there are other ways that Benjamin pointed out.

That said, Doctrine does of course not "take away" access to the foreign keys. With array or scalar hydration or even plain SQL, of course, you can still get the foreign keys in a result but foreign keys have no place in an object model.

Just trying to communicate this better.

I appreciate the time spent on explaining this an do appreciate what you guys have said. I guess one of the things I really liked about the doctrine 2.0 direction was the use of plain php objects (so tempted to so pojos). While this is true there seem to be a number of caveats that get in the way of using those objects exactly how I want to (or in a way that isn't doctrine specific), so these caveats seem to make it a bit more intrusive than I initially thought (though less intrusive than having to extend classes). I'll chalk this one up to keep an eye on and I commend you guys on the work you've done so far.

Whenever you have questions on how to do something properly without dedicated foreign key properties just drop a mail to the user mailing list. For most cases there is a good solution and if not, we will create one.

This is not an issue. Closed

Still there is another issue related to this one.

When I create yaml files from existing database using the command line command "orm:convert-mapping --from-database yaml" the relational field "target_id" is created in both places - as a field and in the relation definition (under oneToOne in my case). Here I get the same problem as described above and the target object cannot be retrieved.

Sample generated yaml for city—country relation:

City:
  type: entity
  table: city
  fields:
    id:
      id: true
      type: integer
      unsigned: false
      nullable: false
      generator:
        strategy: IDENTITY
    countryId:
      type: string(2)
      fixed: true
      nullable: false
      column: country_id
    name:
      type: string(255)
      fixed: false
      nullable: true
  oneToOne:
    country:
      targetEntity: Country
      cascade: {  }
      mappedBy: null
      joinColumns:
        country_id:
          referencedColumnName: id
      orphanRemoval: false
  lifecycleCallbacks: {  }

This yaml causes problems when city is loaded.

Is it a bug or is it just me?

The file attached is modified YAML export driver which workarounds the problem with the problem described in the previous comment.

Also it can append namespace to classes in the YAML files generated from the database schema.

Hope it helps someone.

This should be fixed now.