| | 53 | <h2>Design Implications</h2> |
| | 54 | <p> |
| | 55 | Prado's implementation of Active Record does not maintain referential identity. Each object obtained using |
| | 56 | Active Record is a copy of the data in the database. For example, If you ask for |
| | 57 | a particular customer and get back a <tt>Customer</tt> object, the next time you ask for |
| | 58 | that customer you get back another instance of a <tt>Customer</tt> object. This implies that a strict |
| | 59 | comparison (i.e., using <tt>===</tt>) will return false, while loose comparison (i.e., using <tt>==</tt>) will |
| | 60 | return true if the object values are equal by loose comparison. |
| | 61 | <p> |
| | 62 | <p> |
| | 63 | This is design implication related to the following question. |
| | 64 | <i>"Do you think of the customer as an object, of which there's only one, |
| | 65 | or do you think of the objects you operate on as <b>copies</b> of the database?"</i> |
| | 66 | Other O/R mappings will imply that there is only one Customer object with custID 100, and it literally is that customer. |
| | 67 | If you get the customer and change a field on it, then you have now changed that customer. |
| | 68 | <i>"That constrasts with: you have changed this copy of the customer, but not that copy. |
| | 69 | And if two people update the customer on two copies of the object, whoever updates first, |
| | 70 | or maybe last, wins."</i> [A. Hejlsberg 2003] |
| | 71 | </p> |
| | 72 | |
