Querying in O/R Mappers

I'm confused about performing queries with O/R Mappers, when properties don't map directly to database fields.

Cases like:
* calculated fields ( eg person.getAgeOn(today) -> method returns result of calculation, not simple accessor)
* different subclasses implement field differently (some may store it directly, some may calculate it)
* Methods like getZipCode() { return getAddress().getZipCode(); } which access the fields of a member object

Let's say I need to get all people whose age as of today is >18, or all people whose zipcode is 01234.

I can think of two ways:
A) Retrieve all the objects, and run the method on each one.
B) Write special SQL to do the query.

The obvious downside to A is performance.

The obvious downside to B is that it ruins all the benefits of OO encapsulation, demeter, inheritance, etc. I need to incorporate all of that knoweledge into the finder methods. When different subclasses implement the field differently, this gets into some pretty messy SQL as well.

How do the J2EE pro handle it? How does Hibernate's HQL handle queries on non-accessor fields?

This is the third question today that can be answered by giving a hint towards the formula option when defining a property, which leads to a computed property. That's a nice easy way for me to earn credits.

Concerning your methodological question. The downside of solution B doesn't only enter the field when doing computations on database fields. Data encapsulation even means that no one apart from the object owning the data should access a single field directly. With many fields, this seems overcautious, but if you have a legacy field in a strange format or semantics, it might become meaningful.

The situation is at least improved by using Hibernate's computed properties. Even if you don't express the computation in Java, but in SQL instead, you can get it into your class source (using XDoclet or Annotations), and, AFAIK, you can redefine the formula for each of your subclasses, if that's needed.