Chuck, On 4. 3. 2016, at 5:26, Chuck Hill <[email protected]> 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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
