On Tue, Nov 11, 2008 at 8:45 AM, Lachlan Deck <lachlan.dec..mail.com> 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.
This archive was generated by hypermail 2.0.0 : Tue Nov 11 2008 - 09:05:27 EST