This is a set of slides purely for presentation along with my talk on "Understanding Doctrine" at True North PHP 2013. The content of the presentation is available at https://github.com/shiroyuki/trphp13-demo/blob/master/notes/speaker-note.md.

1. Understanding Doctrine
Juti Noppornpitak

2. Today’s Menu
•
•
•
•
•
What is object relational
mapping?
How is Doctrine designed?
Change Tracking Policy
Proxies and Lazy loading
DBAL or ORM?
•
•
•
•
•
•
Cascading
Doctrine Event System
Second Level Cache
Metadata Cache*
Query Cache*
Result Cache*

3. Juti Noppornpitak
Instaclick Inc., shiroyuki.com, @shiroyuki

4. What is object relational mapping?

5. ow is
H
ned?
esig
ine d
Doctr

6. PROBLEM
Object-relational
impedance mismatch

7. DESIGN
Data Mapper Pattern

8. DESIGN
Unit of Work

9. DESIGN
Repository Pattern

10. Source: http://msdn.microsoft.com/en-us/library/ff649690.aspx

12. Now, it is time for the entrée.

13. Change Tracking Policy

14. Implicit change
tracking policy
known as persisting by (UnitOfWork’s) reachability

15. This means
EntityManager’s persist method is disregarded and
everything reachable/managed by the entity manager,
including an initialized proxy, will be persisted
automatically.

16. Explicit change
tracking policy

17. This means
the code has to explicitly persist to save the data.

18. Notify change tracking
policy

19. This means
the code has full control to explicitly tell UnitOfWork
whether or not the entity is updated.
!
So, even if there is an update, the change can be
discarded as the notify method says there is no change.

20. Proxies
and Lazy
Loading

21. Everything is a proxy.

22. What does it mean?

23. Suppose you have m entities, named a1, a2, ...
and am. During the course of code execution,
we make a lot of queries. Each query makes at
least one proxy per entity in the result set.
Hence, the number of proxies will be around
c×m proxies.

24. Beside retrieving the ID of the proxy, retrieving or
defining properties of a proxy always triggers the
proxy loading if the proxy is set for lazy loading.
!
In this situation, it might lead to making around
cm queries by the end of the execution.

25. Solutions

26. Solution 1
Multiple SELECTs (ORM/DQL)

27. SELECT
FROM
JOIN
WHERE
u, g
User u
u.groups g
u.id = :id

28. Solution 2
SELECT PARTIAL (ORM/DQL)

29. SELECT PARTIAL u.{id, name}
FROM User u
WHERE u.id = :id
or
SELECT PARTIAL u.{id, name},
PARTIAL g.{id, name}
FROM User u
JOIN u.groups g
WHERE u.id = :id

30. Solution 3
Set the fetch mode to “eager”.

31. But it is not
recommended.

32. Why?

38. So, please do not try to use the “eager” mode.

39. DBAL or ORM?

40. Doctrine 2
Common bundle, DBAL bundle and ORM bundle

41. ORM is convenient
but we have to exchange resource for the convenience.

42. Fetching as a hydrate array
instead of an object graph.

44. Database Abstract and
Access Layer (DBAL)
The thin runtime layer to low-level APIs, such as, PDO.

45. When should I use DBAL?

46. Why should I use the
ORM first?

47. C
ascading

48. Supported cascading
operations
DELETE, DETACH, MERGE and PERSIST

49. Cascade on delete

50. DOCTRINE
E
VENT SYSTEM

51. Event Listeners

53. Entity Listeners
New in Doctrine ORM 2.4

55. LifeCycle Event
Callbacks
It is the ugliest but best of all.

57. Let’s leap into the
future

58. SECOND
LEVEL
CACHE

59. How is the second
level cache designed?
for more information, see https://github.com/doctrine/doctrine2/pull/808

60. The cache servers usually
have faster read/write access
than database servers.

61. The cache servers only need to
search from the smaller data set.
This means it is faster to find the
queried data.

62. So, one obvious benefit of using
the second level cache is that we
reduce the access to the
database.

63. A few more things...

64. Other kinds of cache
They are not really visible but worth to mention.

65. Metadata Cache

66. Query Cache

67. Result Cache

68. CONCLUSION

69. THE END
🌏
🐤
http://shiroyuki.com
@shiroyuki