One possibility is to install a custom DataChannel between DataContext
and DataDomain, and intercept and modify certain queries there.
Chaining DataChannels hasn't been tested extensively, so there might
be some pitfalls, but generally this is the easiest way to intercept
all traffic going between the app and the DB.
Andrus
On Nov 11, 2008, at 3:45 PM, Lachlan Deck wrote:
On 11/11/2008, at 11:42 PM, Andrus Adamchik wrote:
On Nov 11, 2008, at 2:30 PM, Lachlan Deck wrote:
Yeah and should you share that model in a framework/lib between
more than one app it really needs to be optional.
I really don't see how you can make it "optional". Entity qualifier
is not optional by design. It is either mapped or not.
That's what I meant. Applied instead by some means during ObjEntity
registration during app launch. I'm not aware of what hooks are
available for this purpose in Cayenne. But I'd prefer to pull them
out if the below suggestion was available instead.
I have a solution in mind for the "library" case - smart mapping
overrides. So that a piece of shared mapping could be modified as
needed by the downstream users, with full reuse of the library
mapping. I started developing that as I needed to customize
listeners per project, but I am sure it can be put to good use in
many other cases.
If you need both qualified and unqualified entity in the same
project, then the more I think about it the more I am convinced
that a solution is to map this as two entities.
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.
with regards,
--
Lachlan Deck
