Re: a trick to model a complex derived relationship?
Re: a trick to model a complex derived relationship?
- Subject: Re: a trick to model a complex derived relationship?
- From: Markus Ruggiero <email@hidden>
- Date: Mon, 14 Mar 2016 11:17:18 +0100
I may be at bit late to the discussion....
Isn't what Chuck described basically a sinlge table inheritance?
You could create SUB-Types based on you User and create separate relationships to each sub-type (NOT to the generic super type!). This should work transparently then.
Model something like this...
User, then AuctionUser as subtype of User, ActionOwner as subtype of User, etc. use single table inheritance with userType as restricting qualifier.
Then model respective relationships:
Auction <<-> ActionOwner
This should allow you to create the needed qualifiers for a fetch.
---markus---
> On 07.03.2016, at 19:12, OC <email@hidden> wrote:
>
> Chuck,
>
> short version: with key (not keypath) restrictingQualifier it, alas, does not work either.
>
> Thanks again a big lot for all the help!
> OC
>
> Long version if anybody interested:
>
> (a) given there are two entities, Source and Destination, and a relationship Source.rel ->> Destination
> (b) and we need to model a “derived relationship” with a behaviour same as e.g., this Java-side implementation gives:
>
> def derivedRel() {
> rel().findAll { it.someAttribute==SOME_VALUE }
> }
>
> the following trick _does not_ work:
>
> (i) define a new entity, FilteredDestination, with a restrictingQualifier "someAttribute = SOME_VALUE"
> (ii) define a new relationship, Source.derivedRel ->> FilteredDestination with same joins as rel has
>
> We hoped that EOF would use the FilteredDestination's restrictingQualifier when resolving Source.derivedRel. Alas, it does not; it simply performs the joins (which were set up through the original "rel" relationship to contain “invalid“ FilteredDestination rows, too), and returns all the rows Source.rel would.
>
> (The restrictingQualifier is properly used when fetching FilteredDestination directly; alas, not when resolving relationships which lead to it /or, in case of flattened ones, go through it/.)
>
>
> On 6. 3. 2016, at 18:38, OC <email@hidden> wrote:
>
>> Chuck,
>>
>> On 4. 3. 2016, at 5:26, Chuck Hill <email@hidden> wrote:
>>
>>>>>> Defining additional entities with the appropriate restricting qualifiers for these conditions might possibly work. Then you could define the flattened relationship in terms of these restricted entities.
>>>>>
>>>>> ... Thank you for the advice; I'll check the possibility of qualified entities (of which I completely have forgot!), it might lead to a cleaner and more efficient code.
>>>>
>>>> Hmmm, let me see whether I understood you properly. At the moment, I have
>>>>
>>>> (a) entities Auction, UserAuction, User
>>>> (b) relationships Auction.userAuction ->> UserAuction and UserAuction.user -> User
>>>>
>>>> For given Auction, I need to model a relationship auctionOwner -> User, defined (for the testing at the moment simply) as
>>>> (i) Auction.userAuction.user exists
>>>> (ii) Auction.userAuction.user.userType==4
>>>>
>>>> So, I have
>>>>
>>>> - defined a new entity OwnerAuction, which is essentially a copy of UserAuction, but contains 'restrictingQualifier = "user.userType = 4";'
>>>
>>> Isn’t that one supposed to restrict accessAllowed?
>>
>> Right. For testing, I sticked with one of the restrictions (which is user type); the other one (accessAllowed) I intended to add later, when this one works.
>>
>>> I think you would want the userType=4 restriction on OwnerAuctionUser (or whatever you want to call it).
>>
>> Aha, so EOF would grant only key (*not* keypath) restrictions when resolving relationships?
>>
>> Should occur to me. I'll try, thanks!
>>
>>>> - defined a new relationship Auction.internalOwnerAuction -> OwnerAuction, with precisely same join as Auction.userAuction
>>>> - defined a flattened relationship Auction.ownerAuction -> User, defined as "internalOwnerAuction.user"
>>>>
>>>> This is what you meant, or did I do something wrong?
>>>
>>> That is not quite what I had in mind, see above.
>>
>> Now I see -- I shall try to make two new entities, each one restricted using only its keys, not keypaths; and hopefully it'll work. We'll see, I'll let you know.
>>
>>> ...
>>> It was just an idea on how you might abuse EOF to achieve your goal. It might not work.
>>
>> Of course, self-evidently EOF was not designed to do things like this, and it'll be rather a luck if it works.
>>
>> If the worst comes to the worst, I can go back to my three-phase-manual implementation, fetching PKs at first, and then “modelling” the conditions by subsequent fetches (the drawback is _considerably_ more complex Java code).
>>
>> Thanks a very big lot,
>> OC
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden