1. Augmenting RDBMS
with MongoDB
for e-commerce

2. My name is
Steve Francia
@spf13

3. • 15+ years building e-commerce
• Long time open source contributor
• Entrepreneur
• Hacker, father, husband, skate punk

4. My name is
Justin Hileman
@bobthecow

5. • 10+ years making the Internet
awesomer
• Open Source contributor
• Vespa rider, swing dancer,
coder, standardista

6. We work for OpenSky
http://shopopensky.com

7. OpenSky is
a new way to shop
OpenSky connects you with innovators,
trendsetters and tastemakers.You choose
the ones you like and each week they invite
you to their private online sales.

8. OpenSky Loves
Open Source
• PHP 5.3
• Apache2
• Symfony2
• Doctrine2
• jQuery
• Mule
• HornetQ
• MongoDB
• nginx
• varnish

9. We contribute to many
open source projects and
pioneer innovative
solutions using them

10. OpenSky was the first
e-commerce site built
on MongoDB
... also the first e-commerce site built on Symfony2

11. Why NoSQL for
e-commerce?
Using the right solution for each situation

12. Data dilemma of
e-commerce
Pick One

13. Data dilemma of
e-commerce
Pick One
• Stick to one vertical (Sane schema)

14. Data dilemma of
e-commerce
Pick One
• Stick to one vertical (Sane schema)
• Flexibility (Insane schema)

15. Sane schema

16. Sane schema
• Works ... for a while

17. Sane schema
• Works ... for a while
• Fine for a few types of products

18. Sane schema
• Works ... for a while
• Fine for a few types of products
• Not possible when more product types
introduced

19. Let’s Use an Example

20. Let’s Use an Example
How about we start with books

21. Book Product Schema
Product {
id:
sku: General Product
product dimensions:
shipping weight: attributes
MSRP:
price:
description:
...
author: Orson Scott Card
title: Enders Game
binding: Hardcover
publication date: July 15, 1994 Book Specific
publisher name: Tor Science Fiction attributes
number of pages: 352
ISBN: 0812550706
language: English
...

22. Seems simple enough

23. Seems simple enough
What happens when we add another vertical...
say music albums

24. Album Product Schema
Product {
id:
sku: General Product
product dimensions: attributes stay the
shipping weight:
MSRP:
same
price:
description:
...
artist: MxPx
title: Panic Album Specific
release date: June 7, 2005 attributes are
label: Side One Dummy
track listing: [ The Darkest ... different
language: English
format: CD
...

25. Okay, it’s getting hairy but
is still manageable, right?

26. Okay, it’s getting hairy but
is still manageable, right?
Now the business want to sell jeans

27. Jeans Product Schema
Product {
id: General Product
sku:
product dimensions:
attributes stay the
shipping weight: same
MSRP:
price:
description:
...
brand: Lucky
gender: Mens
Jeans specific
make: Vintage attributes are totally
style: Straight Cut different ... and not
length: 34
width: 34
consistent across
color: Hipster brands & make
material: Cotten Blend
...

28. Now we’re screwed

29. We need a flexible
schema in RDBMS

30. We need a flexible
schema in RDBMS
We got this ... right?

31. Many approaches
dealing with unknown
unknowns in RDBMS

32. Many approaches
dealing with unknown
unknowns in RDBMS
None work well

33. EAV
as popularized by Magento
“For purposes of flexibility, the Magneto database heavily utilizes
an Entity-Attribute-Value (EAV) data model.
As is often the case, the cost of flexibility is complexity -
Magento is no exception.
The process of manipulating data in Magento is often more
“involved” than that typically experienced using traditional
relational tables.”
- Varien

34. EAV
• Crazy SQL queries
• Hundreds of joins in a query...
or
• Hundreds of queries joined in
the application
• No database enforced integrity

35. Did I say crazy SQL
(this is a single query)

36. Did I say crazy SQL
(this is a single query)
You may have trouble reading this in the back

37. Selecting a single product

38. Single Table Inheritance
(insanely wide tables)
• No data integrity enforcement
• Only can use FK for common
elements
• Very wasteful (but disk is cheap!)
• Can’t effectively index

39. Generic Columns
• No data integrity enforcement
• No data type enforcement
• Only can use FK for common
elements
• Wasteful (but disk is cheap!)
• Can’t index

40. Serialized in Blob
• Not searchable
• No integrity
• All the disadvantages of a document
store, but none of the advantages
• Never should be used
• One exception is Oracle XML
which operates similar to a
document store

41. Concrete Table Inheritance
(a table for each product attribute set)
• Allows for data integrity
• Querying across attribute
sets quite hard to do (lots of
joins, OR statements and full
table scanning)
• New table needs to be
created for each new
attribute set

42. Class table inheritance
(single product table,
each attribute set in own table)
• Likely best solution within the
constraint of SQL
• Supports data type enforcement
• No data integrity enforcement
• Easy querying across categories (for
browse pages) since common data
in single table
• Every set needs a new table
• Requires a ton of forsight, as
changes are very complicated

43. MongoDB to the
Rescue

44. MongoDB to the
Rescue
• Flexible (and sane) Schema

45. MongoDB to the
Rescue
• Flexible (and sane) Schema
• Easily searchable

46. MongoDB to the
Rescue
• Flexible (and sane) Schema
• Easily searchable
• Easily accessible

47. MongoDB to the
Rescue
• Flexible (and sane) Schema
• Easily searchable
• Easily accessible
• Fast

48. Flexible schema

49. { {
sku: "00e8da9c", sku: "00e8da9d",
type: "Audio Album", type: "Film",
title: "Hoss", title: "The Matrix",
description: "by Lagwagon", description: "Set in the 22nd century, Th
asin: "B0000007QG", asin: "B000P0J0AQ",
shipping: { shipping: {
weight: 6, weight: 6,
dimensions: { dimensions: {
width: 10, width: 10,
height: 10, height: 10,
depth: 1 depth: 1
}, },
}, },
pricing: { pricing: {
list: 1000, list: 1200,
retail: 800, retail: 1100,
savings: 200, savings: 100,
pct_savings: 20 pct_savings: 8.5
}, },
details: { details: {
title: "Hoss", title: "The Matrix",

50. pct_savings: 20 pct_savings: 8.5
}, },
details: { details: {
title: "Hoss", title: "The Matrix",
artist: "Lagwagon", director: [ "Andy Wachowski", "Larry Wa
genre: [ "Punk", "Hardcore", "Indie Rock" ], [ "Andy Wachowski", "Larry Wach
writer:
label: "Fat Wreck Chords", actor: [ "Keanu Reeves" , "Lawrence Fis
number_of_discs: 1, genre: [ "Science Fiction", "Action" ],
issue_date: "November 21, 1995", number_of_discs: 1,
format: "CD", issue_date: "May 15 2007",
alternate_formats: [ 'Vinyl', 'MP3' ],original_release_date: "1999",
tracks: [ disc_format: "DVD",
"Kids Don't Like To Share", rating: "R",
"Violins", alternate_formats: [ 'VHS', 'Bluray' ],
"Name Dropping", run_time: "136",
"Bombs Away", studio: "Warner Bros",
"Move The Car", language: "English",
"Sleep", format: [ "AC-3", "Closed-captioned", "
"Sick", aspect_ratio: "1.66:1"
"Rifle", },
"Weak", }
"Black Eye",
"Bro Dependent",
"Razor Burn",
"Shaving Your Head",
"Ride The Snake",
],

51. Queries

52. db.products.find( { 'name': "The Matrix" } );

53. db.products.find( { 'name': "The Matrix" } );
{
"_id": ObjectId("4d8ad78b46b731a22943d3d3"),
"sku": "00e8da9d",
"type": "Film",
"name": "The Matrix",
"description": "Set in the 22nd century, The Matrix...",
"asin": "B000P0J0AQ",
"shipping": {
"weight": 6,
"dimensions": {
"width": 10,
"height": 10,
"depth": 1
}
},
"pricing": {

54. db.products.find( { 'details.actor': "Groucho Marx" } );

55. db.products.find( { 'details.actor': "Groucho Marx" } );
},
"pricing": {
"list": 1000,
"retail": 800,
"savings": 200,
"pct_savings": 20
},
"details": {
"title": "A Night at the Opera",
"director": "Sam Wood",
"actor": ["Groucho Marx", "Chico Marx", "Harpo Marx"],
"genre": "Comedy",
"number_of_discs": 1,
"issue_date": "May 4 2004",
"original_release_date": "1935",
"disc_format": "DVD",

56. db.products.find( {
'details.genre': "Jazz", 'details.format': "CD"
} );

57. db.products.find( {
'details.genre': "Jazz", 'details.format': "CD"
} );
"list": 1200,
"retail": 1100,
"savings": 100,
"pct_savings": 8
},
"details": {
"title": "A Love Supreme [Original Recording Reissued]",
"artist": "John Coltrane",
"genre": ["Jazz", "General"],
"format": "CD",
"label": "Impulse Records",
"number_of_discs": 1,
"issue_date": "December 9, 1964",
"alternate_formats": ["Vinyl", "MP3"],
"tracks": [
"A Love Supreme Part I: Acknowledgement",

58. db.products.find( { 'details.actor':
{ $all: ['James Stewart', 'Donna Reed'] }
} );

59. db.products.find( { 'details.actor':
{ $all: ['James Stewart', 'Donna Reed'] }
} );
},
"details": {
"title": "It's a Wonderful Life",
"director": "Frank Capra",
"actor": ["James Stewart", "Donna Reed", "Lionel Barrymore"],
"writer": [
"Frank Capra",
"Albert Hackett",
"Frances Goodrich",
"Jo Swerling",
"Michael Wilson"
],
"genre": "Drama",
"number_of_discs": 1,
"issue_date": "Oct 31 2006",
"original_release_date": "1947",

60. Wanna Play?
• grab products.js from
http://github.com/spf13/mongoProducts
• mongo --shell products.js
• > use mongoProducts

61. Embedded documents
are great for orders
• Ordered items need to be fixed at the time
of purchase
• Embed them right in the order
db.order.find( { 'items.sku': '00e8da9f' } );
db.order.find( {
'items.details.actor': 'James Stewart'
} ).count();

62. Why not NoSQL?
Using the right solution for each situation

63. Data (like people) are
really sensitive when it
comes to money

64. Stricter data
requirements for $$

65. Stricter data
requirements for $$
• For financial systems any data inconsistency
is unacceptable

66. Stricter data
requirements for $$
• For financial systems any data inconsistency
is unacceptable
• Perhaps you’ve heard of ACID?

67. What about ACID?

68. What about ACID?
Q: Is MongoDB ACID?

69. What about ACID?
Q: Is MongoDB ACID?
A: Kinda

70. Atomicity

71. Atomicity
• MongoDB does atomic writes

72. Atomicity
• MongoDB does atomic writes
... for single document changesets

73. Atomicity
• MongoDB does atomic writes
... for single document changesets
• $set, $unset, $inc, $push,
$pushAll, $pull, $pullAll, $bit

74. Consistency

75. Consistency
• MongoDB can enforce unique keys

76. Consistency
• MongoDB can enforce unique keys
... but only on keys shared by every
document in the collection

77. Consistency
• MongoDB can enforce unique keys
... but only on keys shared by every
document in the collection
• MongoDB can't enforce referential integrity

78. Isolation

79. Isolation
• // Pseudo-isolated updates
db.foo.update( { x : 1 } , { $inc : { y : 1 } } , false , true );

80. Isolation
• // Pseudo-isolated updates
db.foo.update( { x : 1 } , { $inc : { y : 1 } } , false , true );
• // Isolated updates
db.foo.update( { x : 1 , $atomic : 1 } , { $inc : { y : 1 } } , false ,
true );

81. Isolation
• // Pseudo-isolated updates
db.foo.update( { x : 1 } , { $inc : { y : 1 } } , false , true );
• // Isolated updates
db.foo.update( { x : 1 , $atomic : 1 } , { $inc : { y : 1 } } , false ,
true );
• But there are caveats...

82. Isolation
• // Pseudo-isolated updates
db.foo.update( { x : 1 } , { $inc : { y : 1 } } , false , true );
• // Isolated updates
db.foo.update( { x : 1 , $atomic : 1 } , { $inc : { y : 1 } } , false ,
true );
• But there are caveats...
• Despite the $atomic keyword, this is not an atomic update,
since atomicity implies “all or nothing”

83. Isolation
• // Pseudo-isolated updates
db.foo.update( { x : 1 } , { $inc : { y : 1 } } , false , true );
• // Isolated updates
db.foo.update( { x : 1 , $atomic : 1 } , { $inc : { y : 1 } } , false ,
true );
• But there are caveats...
• Despite the $atomic keyword, this is not an atomic update,
since atomicity implies “all or nothing”
• An isolated update can only act on a single collection. Multi-
collection updates are not transactional, thus not isolatable.

84. Durability

85. Durability
• Mongo has this one covered

86. What does
MongoDB Support?

88. • Atomic single document writes
• If you need atomic writes across multi-document
transactions don't use Mongo
• Many e-commerce transactions could be
accomplished within a single document write

89. • Atomic single document writes
• If you need atomic writes across multi-document
transactions don't use Mongo
• Many e-commerce transactions could be
accomplished within a single document write
• Unique indexes
• This only works on keys used by the entire collection

90. • Atomic single document writes
• If you need atomic writes across multi-document
transactions don't use Mongo
• Many e-commerce transactions could be
accomplished within a single document write
• Unique indexes
• This only works on keys used by the entire collection
• Isolated (not atomic) single collection updates.
• Mongo does not support locking
• There are ways to work around this

91. • Atomic single document writes
• If you need atomic writes across multi-document
transactions don't use Mongo
• Many e-commerce transactions could be
accomplished within a single document write
• Unique indexes
• This only works on keys used by the entire collection
• Isolated (not atomic) single collection updates.
• Mongo does not support locking
• There are ways to work around this
• It’s durable

92. There are ways to
guarantee ACID properties
in inconsistent databases

93. There are ways to
guarantee ACID properties
in inconsistent databases
(or, as we call them, consistency impaired databases)

94. Optimistic concurrency

95. Optimistic concurrency
• Read the current state of a product

96. Optimistic concurrency
• Read the current state of a product
• Make your changes with the assertion that
your product has the same state as it did
when you last read it

97. Optimistic concurrency
in MongoDB

98. Optimistic concurrency
in MongoDB
We’ll use an update-if-current strategy.

99. Optimistic concurrency
in MongoDB
We’ll use an update-if-current strategy.
This example is straight from the documentation:

100. Optimistic concurrency
in MongoDB
We’ll use an update-if-current strategy.
This example is straight from the documentation:
> t = db.inventory
> p = t.findOne({sku:'abc'})
> t.update({_id:p._id, qty:p.qty}, {'$inc': {qty: -1}});
> db.$cmd.findOne({getlasterror:1});
{"err" : , "updatedExisting" : true , "n" : 1 , "ok" : 1}
// it worked

101. Optimistic concurrency
in MongoDB
We’ll use an update-if-current strategy.
This example is straight from the documentation:
> t = db.inventory
> p = t.findOne({sku:'abc'})
> t.update({_id:p._id, qty:p.qty}, {'$inc': {qty: -1}});
> db.$cmd.findOne({getlasterror:1});
{"err" : , "updatedExisting" : true , "n" : 1 , "ok" : 1}
// it worked
... If that didn't work, try again until it does.

102. Optimistic concurrency
• Read the current state of a product.
• Make your changes with the assertion that
your product has the same state as it did
when you last read it.

103. Optimistic concurrency
• Read the current state of a product.
• Make your changes with the assertion that
your product has the same state as it did
when you last read it.
• It's possible to use OCC to bootstrap
pessimistic concurrency and fake row level
locking

104. Optimistic concurrency
• Read the current state of a product.
• Make your changes with the assertion that
your product has the same state as it did
when you last read it.
• It's possible to use OCC to bootstrap
pessimistic concurrency and fake row level
locking
... ask me about this some time

105. Optimistic concurrency
control assumes an
environment with low
data contention

106. OCC works great for
companies like Amazon
• Amazon has a long-tail catalog
• A long tail catalog lends itself well to
optimistic concurrency, because it has low
data contention

107. OCC fails miserably for

108. OCC fails miserably for
• eBay

109. OCC fails miserably for
• eBay
• Gilt

110. OCC fails miserably for
• eBay
• Gilt
• Groupon

111. OCC fails miserably for
• eBay
• Gilt
• Groupon
• OpenSky

112. OCC fails miserably for
• eBay
• Gilt
• Groupon
• OpenSky
• Living Social

113. OCC fails miserably for
• eBay
• Gilt
• Groupon
• OpenSky
• Living Social
• InsertFlashSaleSiteOfTheMinute

114. Flash sales and auctions
are defined by high data
contention

115. Flash sales and auctions
are defined by high data
contention
• The model doesn't work otherwise

116. Flash sales and auctions
are defined by high data
contention
• The model doesn't work otherwise
• They can't afford to be optimistic

117. Can we use pessimistic
concurrency with a
distributed NoSQL
database?

118. Yep.

119. Blending
NoSQL & RDBMS
Using the right solution for each situation

120. Our goal is to put as much
in Mongo as possible
• What makes more sense in RDBMS?
• Inventory
• Orders

121. Inventory requires
• Row level locking (or table level locking)

122. Orders require
• Row level locking (or table level locking)
• Atomic writes (inventory decremented)
• Transactions (3rd party processing)

123. Inventory & checkout
transactions

124. Commerce is ACID
In Real Life

126. 1. I go to Barneys and see a pair of shoes I just have to
buy.

127. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).

128. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).
3. I take them up to the cash register and purchase them:

129. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).
3. I take them up to the cash register and purchase them:
• Store inventory has been manually decremented.

130. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).
3. I take them up to the cash register and purchase them:
• Store inventory has been manually decremented.
• I pay for them with my trusty AmEx.

131. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).
3. I take them up to the cash register and purchase them:
• Store inventory has been manually decremented.
• I pay for them with my trusty AmEx.
4. If all goes according to plan, I walk out of the store.

132. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).
3. I take them up to the cash register and purchase them:
• Store inventory has been manually decremented.
• I pay for them with my trusty AmEx.
4. If all goes according to plan, I walk out of the store.
5. If my card was declined, the shoes are “rolled back”

133. 1. I go to Barneys and see a pair of shoes I just have to
buy.
2. I call “dibs” (by grabbing them off the shelf).
3. I take them up to the cash register and purchase them:
• Store inventory has been manually decremented.
• I pay for them with my trusty AmEx.
4. If all goes according to plan, I walk out of the store.
5. If my card was declined, the shoes are “rolled back”
... out onto the shelves and sold to the next customer
who wants them.

134. We follow the same
model for e-commerce

136. 1. Select a product.

137. 1. Select a product.
2. Lock the row or table and confirm inventory.

138. 1. Select a product.
2. Lock the row or table and confirm inventory.
3. Purchase the product:

139. 1. Select a product.
2. Lock the row or table and confirm inventory.
3. Purchase the product:
• Decrement product inventory

140. 1. Select a product.
2. Lock the row or table and confirm inventory.
3. Purchase the product:
• Decrement product inventory
• Process payment

141. 1. Select a product.
2. Lock the row or table and confirm inventory.
3. Purchase the product:
• Decrement product inventory
• Process payment
4. Commit the transaction.

142. 1. Select a product.
2. Lock the row or table and confirm inventory.
3. Purchase the product:
• Decrement product inventory
• Process payment
4. Commit the transaction.
5. Roll back if anything went wrong.

143. Doctrine (ORM/ODM)
to the rescue

144. Doctrine (ORM/ODM)
to the rescue
It would be possible without them,
but we're not that masochistic

145. Data we store in SQL
• Order
• Order/Shipment
• Order/Transaction
• Inventory

146. Data we store in
MongoDB

147. Data we store in
MongoDB
• User • Event
• Product • TaxRate
• Product/Sellable • ... and then I got tired of
typing them in
• Address
• Just imagine this list has
• Cart 40 more classes
• CreditCard • ...

148. We have the
most boring SQL
schema ever

149. CREATE TABLE `product_inventory` (
`product_id` char(32) NOT NULL,
`inventory` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`product_id`)
);
CREATE TABLE `sellable_inventory` (
`sellable_id` char(32) NOT NULL,
`inventory` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`sellable_id`)
);
CREATE TABLE `orders` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` char(32) NOT NULL,
`shippingName` varchar(255) DEFAULT NULL,
`shippingAddress1` varchar(255) DEFAULT NULL,
`shippingAddress2` varchar(255) DEFAULT NULL,
`shippingCity` varchar(255) DEFAULT NULL,
`shippingState` varchar(2) DEFAULT NULL,
`shippingZip` varchar(255) DEFAULT NULL,
`billingName` varchar(255) DEFAULT NULL,
`billingAddress1` varchar(255) DEFAULT NULL,
`billingAddress2` varchar(255) DEFAULT NULL,
`billingCity` varchar(255) DEFAULT NULL,

150. Wait. How does
inventory live in SQL?
Isn’t that a property in one of your Mongo collections?

151. I thought you’d
never ask!

152. CREATE TABLE `product_inventory` (
`product_id` char(32) NOT NULL,
`inventory` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`product_id`)
);
CREATE TABLE `sellable_inventory` (
`sellable_id` char(32) NOT NULL,
`inventory` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`sellable_id`)
);
CREATE TABLE `orders` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` char(32) NOT NULL,
`shippingName` varchar(255) DEFAULT NULL,
`shippingAddress1` varchar(255) DEFAULT NULL,
`shippingAddress2` varchar(255) DEFAULT NULL,
`shippingCity` varchar(255) DEFAULT NULL,
`shippingState` varchar(2) DEFAULT NULL,
`shippingZip` varchar(255) DEFAULT NULL,
`billingName` varchar(255) DEFAULT NULL,
`billingAddress1` varchar(255) DEFAULT NULL,
`billingAddress2` varchar(255) DEFAULT NULL,
`billingCity` varchar(255) DEFAULT NULL,

153. Inventory is transient
• Product::$inventory is effectively a
transient property
• Note how I said “effectively”? ... we cheat
and persist our transient property to
MongoDB as well
• We can do this because we never really
trust the value stored in Mongo

154. Accuracy is only important
when there’s contention

155. Accuracy is only important
when there’s contention
• For display, sorting and alerts, we can use
the value stashed in MongoDB
• It’s faster
• It’s accurate enough

156. Accuracy is only important
when there’s contention
• For display, sorting and alerts, we can use
the value stashed in MongoDB
• It’s faster
• It’s accurate enough
• For financial transactions, we want the
security and comfort of our RDBMS.

157. We keep inventory in
sync with listeners

158. We keep inventory in
sync with listeners
• Every time a new product is created, its
inventory is inserted in SQL

159. We keep inventory in
sync with listeners
• Every time a new product is created, its
inventory is inserted in SQL
• Every time an order is placed, inventory is
verified and decremented

160. We keep inventory in
sync with listeners
• Every time a new product is created, its
inventory is inserted in SQL
• Every time an order is placed, inventory is
verified and decremented
• Whenever the SQL inventory changes, it is
saved to MongoDB as well

161. Be careful what you lock

162. Be careful what you lock
1. Acquire inventory row lock and begin transaction
2. Check current product inventory
3. Decrement product inventory
4. Write the Order to SQL
5. Update affected MongoDB documents
6. Commit the transaction
7. Release product inventory lock

163. Making MongoDB
and RDBMS relations
play nice

164. Products are
documents stored
in MongoDB

165. /** @mongodb:Document(collection="products") */
class Product
{
/** @mongodb:Id */
private $id;
/** @mongodb:String */
private $title;
public function getId()
{
return $this->id;
}
public function getTitle()
{
return $this->title;
}
public function setTitle($title)
{
$this->title = $title;
}
}

166. Orders are entities
stored in an RDBMS

167. /**
* @orm:Entity
* @orm:Table(name="orders")
* @orm:HasLifecycleCallbacks
*/
class Order
{
/**
* @orm:Id @orm:Column(type="integer")
* @orm:GeneratedValue(strategy="AUTO")
*/
private $id;
/**
* @orm:Column(type="string")
*/
private $productId;
/**
* @var DocumentsProduct
*/
private $product;
// ...
}

168. So how does an
RDBMS have a
reference to something
outside the database?

169. Setting the Product
class Order {
// ...
public function setProduct(Product $product)
{
$this->productId = $product->getId();
$this->product = $product;
}
}

170. • $productId is mapped and persisted
• $product which stores the Product
instance is not a persistent entity property

171. Retrieving our
product later

172. OrderPostLoadListener
use DoctrineORMEventLifecycleEventArgs;
class OrderPostLoadListener
{
public function postLoad(LifecycleEventArgs $eventArgs)
{
// get the order entity
$order = $eventArgs->getEntity();
// get odm reference to order.product_id
$productId = $order->getProductId();
$product = $this->dm->getReference('MyBundle:DocumentProduct', $productId);
// set the product on the order
$em = $eventArgs->getEntityManager();
$productReflProp = $em->getClassMetadata('MyBundle:EntityOrder')
->reflClass->getProperty('product');
$productReflProp->setAccessible(true);
$productReflProp->setValue($order, $product);
}
}

173. All Together Now
// Create a new product and order
$product = new Product();
$product->setTitle('Test Product');
$dm->persist($product);
$dm->flush();
$order = new Order();
$order->setProduct($product);
$em->persist($order);
$em->flush();
// Find the order later
$order = $em->find('Order', $order->getId());
// Instance of an uninitialized product proxy
$product = $order->getProduct();
// Initializes proxy and queries the monogodb database
echo "Order Title: " . $product->getTitle();
print_r($order);

174. Read more about
this technique
Jon Wage, one of OpenSky’s engineers, first
wrote about this technique on his personal
blog: http://jwage.com
You can read the full article here:
http://jwage.com/2010/08/25/blending-the-
doctrine-orm-and-mongodb-odm/

175. Questions?
http://spf13.com
@spf13
http://justinhileman.com
@bobthecow
http://shopopensky.com
PS: We’re hiring!! Contact us at
jobs@shopopensky.com