An unsaved Entity (say, a new `Order` object) doesn't yet have a database-assigned id — it's null until the first save. If equals() is implemented purely by comparing id, what breaks when two such transient, not-yet-persisted Order instances are compared or placed in a hash-based collection, and how do teams typically handle Entity equality before an id exists?

## Where the simple rule collides with persistence Entity equality sounds simple — 'compare by id, ignore everything else' — but it collides with a common wrinkle: many persistence technologies (relational databases with auto-increment primary keys, or ORMs like JPA/Hibernate with `@GeneratedValue`) don't assign identity until the object is actually written to the database. Before that first save/flush, the object is 'transient' and its id field is null. ## What goes wrong, step by step 1. If `equals()` is `return this.id != null && this.id.equals(other.id)` (a common 'safe' pattern), two different transient `Order` instances — freshly constructed, never saved, both with `id == null` — will both evaluate the guard as false against each other, so `equals()` returns false for both. 2. That specific pattern is safe in isolation, but it produces a subtler defect: because `equals()` and `hashCode()` effectively return 'not equal to anything', a `HashSet/HashMap` built while the entity is transient will silently 'lose' the entity after it's saved and its id changes from null to a real value, because `hashCode()` (which typically also depends on id) shifts, and the collection's bucket no longer matches. 3. The object is technically still there, but `contains()`, `remove()`, and `get()` stop finding it. ## Why the persistence layer works this way This exists because ORMs need a stable storage handle, and the cheapest way to get uniqueness at scale in a relational database is an auto-incrementing surrogate key assigned by the database at insert time. But the domain model conceptually needs identity from the moment the Entity is created in memory, because business logic (deduplication, equality checks in service code, adding an Entity to a Set before it's persisted) routinely runs before the first save. ## The three ways out, and what each costs The trade-off between resolutions is real. - **Falling back to Object/reference equality** for the transient case is simplest and avoids the hashCode-shifts-after-save bug entirely, since reference equality never changes — but `equals()` is meaningless as 'business equality' while the object lives in memory before persistence, which surprises developers who expect DDD Entities to always compare 'properly'. - **Generating identity client-side** — a UUID (v4 or v7), a Snowflake-style id, or a typed ID wrapping one of those — solves this cleanly: identity exists at construction time, is immutable for the object's entire lifetime including before-and-after persistence, and `equals()`/`hashCode()` work correctly from the moment the constructor runs. The cost: compact sequential integer keys are worse for some database index locality/page-fill characteristics and worse for humans reading foreign keys in ad hoc SQL, and you take on the responsibility of guaranteeing uniqueness yourself (UUIDs make collisions astronomically unlikely, so this is rarely a real cost). - **A weaker third option** — comparing on a natural/business key known pre-save — only works when such a key genuinely exists and is guaranteed unique before persistence. ## The failure signature in production In production, the failure signature of the naive approach shows up as 'objects disappearing from collections after save' or 'duplicate detection working in unit tests but not in integration tests.' A frequently-cited example: a shopping cart implemented as `Set<OrderLine>` where OrderLine is an Entity with a database-generated id. The cart correctly rejects duplicate line-additions while being built in memory (each OrderLine is a distinct transient object, distinct by reference), but after the cart is saved and reloaded within the same session, `hashCode()` (now based on the freshly-populated id) differs from what it would have been pre-save; if the same in-memory Set instance straddles that boundary, `contains()` checks against it can spuriously report 'not found' for an OrderLine that's actually present. The standard, well-documented fix in the Hibernate community is exactly what's described above: give every Entity a client-generated UUID (or a business key) assigned at construction, and never base `equals()`/`hashCode()` on a database-generated surrogate key alone.