I have recently been in a few conversations regarding Transparent Persistence.
Is it possible to have 100% transparent persistence?
Not within Java. There is an impedence mismatch between objects and relational. You don’t “delete” an object in Java. You let it go out of scope, or you set it to null, or something else. What would it mean to delete the object?
How would you query for objects? We need some kind of API/QL to do this
Oh man, so we DON’T have transparent persistence. Woe is me. We are doomed
It isn’t bad that we don’t have fully transparent persistence. I think it is actually a GOOD thing. As soon as you go into the way of data and persistence the rules change, and you may want to do things differently. However, for many of the things that you do, you want to basically be working with objects and have persistence taken care of for you. What we DON’T want to do, is the manual mapping between objects and JDBC/SQL. Or manually working with connections, and statements, and all that garbage :)
So. With JDO (and Hibernate and Cayenne and …) we have a good level of transparency, but we are allowed to get in there when we need too.
However, maybe we are doing OR mapping all wrong
(NOTE: Google. How about hiring Brian and funding him to do this work?)
September 2nd, 2004 at 8:30 am
We are deifnately off topic for Dion’s post. I am talking about a different way to view the cache and system design, which instead of the cache being the “check here before you load this thing” is a “go through it to load” where the cache handles the database access and the client talks to the cache.
I was, and will in the future, try to avoid calling it a cache though as a cache has a very different connotation.
There are big drawbacks — if you cannot use optimistic transactions on the majority of the data there is no benefit at all, for example. Also, the mapping has to be extremely good or the small impedence (collection on bar contains foo, foo has reference to bar and the ref or colelction changes — the relationship is one way in the db, what happens?) problem will magnify quickly.
These are solvable problems though, and I think the benefits probably outweigh the drawbacks in the majority of cases. The process of implementing it, though, is basically implementing a local database backed by a remote database.
-Brian