Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of mkienenb@gmail.com designates
 74.125.82.47 as permitted sender)
MIME-Version: 1.0
From: Mike Kienenberger <mkienenb@gmail.com>
Date: Tue, 24 Sep 2013 15:50:10 -0400
Message-ID: 
 <CAM1yOjbSfTBjLHaEOkB+y9G+LS+VVycmYAUGAjj2QsJxZeYqNw@mail.gmail.com>
Subject: No longer execute sql for relationships during optimistic locking
 which are not used for locking?
To: dev@cayenne.apache.org
Content-Type: text/plain; charset=ISO-8859-1

The third case where I use DataContextDelegate which I mentioned
earlier is new, due to a change in behavior between 1.1 and now (I
think the change happened in 1.2).   I could probably use a
DataChannelFilter here too, or I could also use a custom ServerRuntime
to fix this one, but I'm hoping that we can treat this change as a bug
and fix it instead.

As I mentioned before, I have a non-Mandatory one-to-one relationship
between User and PotentialCustomer.    User always exists, but some
Users have a matching PotentialCustomer record.    Before, if the user
-> PotentialCustomer relationship wasn't referenced with
user.getPotentialCustomer() or something similar, the "Select * from
Potential_Customer where user.id = potential_customer.id" sql was
never executed.   Now this query is always executed due to that change
in how optimistic locking setup works, but it doesn't seem necessary
to do so.

The Potential_customer table only exists in certain environments, so I
set up willPerformQuery() to intercept RelationshipQueries between
User and PotentialCustomer and always return empty results instead of
executing the sql when run in environments where the table doesn't
exist.

I suppose another approach I could take would be to set up a separate
data domain for this table and others like them now that the runtime
is more flexible.

In any case, I have a lot of potential workarounds if we don't fix the
change in behavior.