On Tue, Nov 11, 2008 at 8:45 AM, Lachlan Deck <[EMAIL PROTECTED]> wrote: > What about what I suggested before? i.e., the delegate option (or something > similar) where you can optionally inject an auxiliary expression and/or > orderings (if null) for each query. Mapping separate entities sounds like it > would make it difficult to re-use existing logic for an entity. > > e.g., by default a fetch of objects would apply a restricting qualifier > (e.g., for public viewing) but the background service I'm working on picks > up a list of records that were committed and seeks to operate on them even > if they were marked as deleted.
DataContext Delegation is how restricting qualifiers originally could be implemented in Cayenne 1.1. You could override willPerformSelect() to modify the query. public GenericSelectQuery willPerformSelect(DataContext dataContext, GenericSelectQuery genericSelectQuery) That allowed you to be able to turn them on and off at will, as well as change the restricting qualifier. I think there are a large enough set of us who need the "record is marked as deleted" functionality that the framework should make it easy for us to handle these cases. I know in my own particular case, there's only one exception where I disable the restricting qualifier, then re-enable it. I see Andrus just posted something similar while I was writing this -- not surprising since Andrus helped me with the original implementation years back. I can post the class I have for Cayenne 1.1 to give some ideas, although there's a known race condition in how I've implemented it. The way I did it also requires that the restricting qualifier be specified in code, although there's no reason why it couldn't be done another way.
