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
>
>
This archive was generated by hypermail 2.0.0 : Tue Nov 11 2008 - 09:00:25 EST