Persistence ignorance and DDD reality

Persistence ignorance and DDD reality

I'm trying to implement fully valid persistence ignorance with little
effort. I have many questions though:
The simplest option
It's really straightforward - is it okay to have Entities annotated with
Spring Data annotations just like in SOA (but make them really do the
logic)? What are the consequences other than having to use persistance
annotation in the Entities, which doesn't really follow PI principle? I
mean is it really the case with Spring Data - it provides nice
repositories which do what repositories in DDD should do. The problem is
with Entities themself then...
The harder option
In order to make an Entity unaware of where the data it operates on came
from it is natural to inject that data as an interface through
constructor. Another advantage is that we always could perform lazy
loading - which we have by default in Neo4j graph database for instance.
The drawback is that Aggregates (which compose of Entities) will be
totally aware of all data even if they don't use them - possibly it could
led to debugging difficulties as data is totally exposed (DAO's would be
hierarchical just like Aggregates). This would also force us to use some
adapters for the repositories as they doesn't store real Entities
anymore... And any translation is ugly... Another thing is that we cannot
instantiate an Entity without such DAO - though there could be in-memory
implementations in domain... again, more layers. Some say that injecting
DAOs does break PI too.
The hardest option
The Entity could be wrapped around a lazy-loader which decides where data
should come from. It could be both in-memory and in-database, and it could
handle any operations which need transactions and so on. Complex layer
though, but might be generic to some extent perhaps...? Have a read about
it here
Do you know any other solution? Or maybe I'm missing something in
mentioned ones. Please share your thoughts!